Hola,
Has borrado relation/9520125/history. ¿Fue intencional?
Atentamente,
Andy

Hello,
You've deleted relation/9520125/history here - was that deliberate?
Best Regards,
Andy

Hello,
Just for info, you can check for gaps in relations by a site such as e.g. http://ra.osmsurround.org/analyzeRelation?relationId=19918287 and http://ra.osmsurround.org/analyzeMap?relationId=19918287 .
Best Regards,
Andy

Hello,
Currently, the NCN1 here is relation/254838#map=11/57.6573/-3.2677 , and the EV1 is relation/2763769#map=12/57.6646/-3.2667 . Should more of the ways that are in NCN1 also be in EV1? Currently many to the south aren't, and to the north places like relation/2763769#map=20/57.6635565/-3.2300663 perhaps should not be?
Best Regards,
Andy

No reply, so I filled in the gap again in changeset/176194664 .

Hello,
There's still a bit of a gap in section 2 of the London LOOP: relation/3308902#map=15/51.40058/0.08141 . Previously it ran on this alighnment: https://overpass-turbo.eu/s/2hBx .
Best Regards,
Andy

Now down to 333 - thanks!

Hello nimat223322 and welcome to OpenStreetMap!

I'm a bit puzzled by this edit - you've said that this isn't a building any more yet has 3 levels?.

Also I don't understand why your comment above is "Ordnance Survey (c) Crown Copyright 2020. All rights reserved. Scale 1:1250"? We can't use regular Ordnance Survey maps as a source for OSM, but I'm not convinced that you have here - can you explain what you were trying to do?
Best Regards,
Andy

Thanks!

Just to be clear, my example above IS named with that name in the real world - I specifically checked because the name rhat had been added looks like a spreadsheet faux pas. However, that's what the sign on it says - it is definitely a "name".
If you have surveyed to check that it is not named in the real world, then reflecting that info in OSM does make sense, of course.

Some of these things really have verifiable names - way/731794606 is an example (I was surprised by that because it looks like an import error, but isn't)

Please see forum discussion https://community.openstreetmap.org/t/wikidata-osm-cross-project-vandalism-report/139298

Hello,
Please use better changeset comments than simply "." - use words that describe what you did and explain why.
In this case, you seem to be removing a "landuse=military" that you yourself added 3 months ago.
It is clearly not very secret, since the bus stop outside has the name "군부대앞" ("In front of the military base")
Best Regards,
Andy

Answering that:
> To be clear, the English name is Dokdo

No, it really isn't. That's just an anglicisation of the Korean name.

> I'll change that back
Please don't do that. I'm trying to sort things out on behalf of the Data Working Group (see changeset/174912300 ) so that (a) the fact that these islands are under Korean control is recognised in OSM and (b) everyone who has other ways of describing them can use those too.

> OpenStreetMap information should be based on data from the country that is in effective control

No, that is incorrect. See https://osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf for details.

(for international readers, that comment above translates as "That's not the official name. Dokdo is currently under the effective control of the Republic of Korea, but the South Korean Ministry of Foreign Affairs doesn't use names like "Riancourt Rocks." To be clear, the English name is Dokdo. I'll change that back. OpenStreetMap information should be based on data from the country that is in effective control.")

Thanks!

Problems are easy to find - relation/5371741/history is one. The original relation was tagged as amenity=school but was a type=site relation, you added education=school and someone then removed amenity=school from that and added it to the outer way way/29083822 .
The overpass query to find these problems is https://overpass-turbo.eu/s/2hfT - change the area of that to look elsewhere.

The osm.wiki/Proposal_process page contains the text "Also, a vote result is never permission for large-scale re-tagging of existing objects. See automated Edits code of conduct for more about this topic. " (and osm.wiki/ES:Procedimiento_de_propuesta likewise "Además, nunca utilices el resultado de una votación como justificación para el reetiquetado a gran escala de objetos existentes. Véase el código de conducta de ediciones automatizadas para más detalles sobre este tema. ").
I don't think that a revert will solve the problem, since any iD edits will just force the tag back in, but you will now need to monitor and manage the 20k objects you have edited to check for problems.

(see also comments on changeset/145120734 and changeset/141126341 )

Actually changeset/163106660 (by a different mapper, ages ago) looks odd too.