Check e.g. osm.wiki/Limitations_on_mapping_private_information

Note that this particular case is not mentioned here, but things that are listed there as not allowed are much less problematic according to law.

The ethnicity of people is considered as private information that needs special protection by law in many places, e.g. by GPDR and CCPA. Having this kind of information in an open database would make use of OSM almost impossible in these areas. I also remember several discussions with the result that a geo-database lime OSM is not the right place for this kind of information.

The area is still tagged as being a landslide. I only removed the mispelled "landuse_2" tag. If you think that
natural=landslide describes the situation better than landuse=scree (which was there for years and never changed), feel free to change the natural=* tag to the better value.

May I suggest to discuss these fundamental questions about the definition of the surface tag in the forums or mailing lists? A changeset discussion is not the right place for that.

Hi,
it seems all the tags with a # are already part of the common tag monitoring:gps and can be removed.

Regarding the official coordinates, you might find something in the various discussions and proposals around survey point tagging.

Hi,
what is the vehicle you refer to? "escooter" is a very ambiguous term which shouldn't be used in OSM.
There's a proposal for better terms here:
osm.wiki/Proposal:ElectricScooters
If you want to participate, you're very welcome!

Hi,
what is the meaning of "morehouse:src"? This tag is not documented and not used in any other place.

It's just not possible to inform each and every user whose tags I change. In this changeset alone this would mean to check 14 objects for their history to figure out who added which tag in which changeset I have to leave a comment on.

"compacted:material" won't solve the issue - the actual surface material will be hidden for all tools that are not aware of your new and undocumented tag.
If we follow your line of thought the actual tagging would need to be
surface=paved
paved=compacted
compacted=limestone
... which clearly is not useful.

Key:surface explicitly allows for custom values, and this is in use in various states and countries.

'crushed_limestone' is among the 70th most common surface values. It's better to use this value directly in the surface tag compared to inventing a new key that no common tool knows about.

Hi,
please check the tags you add - 'he_ref' should be 'HE_ref'.

Hi,
could you explain why you added these tags to these buildings? What was incorrect before?
Please note that in OSM we have to use well-defined tags - only these can be understood by other mappers and applications. Please use only those tags that are available as presets in your editor or are documented in the Wiki.

Hi,
not quite... the new scheme would be parking:right:restriction=no_parking. But my edit here was clearly a mistake. Feel free to correct it or I'll do it later.

Hi,
what's the meaning of the tag "attached" on street_lamps? This isn't used in any other place.

Tags with several values are a well-supported feature in OSM. The recommended syntax is to have a semicolon-separated list. Your proposal of adding number to keys is not a generally accepted scheme. I only know of few tags for which this is an official scheme, e.g. 'seamark' and 'inscription' in cases the 255 characters of the value are not sufficient.

Which "tools" don't understand semicolon-separated values in additional tags? As this is a major feature of many tags I'd argue that these tools are broken and need to be fixed.

Coming back to 'wikidata': There are 0 tags with a :N suffix in the database, but two dozen with several semicolon-separated values.
Fixing / documenting issues in the wikidata database doesn't seem to be something that should be in the OSM database.

Thanks!
Both
hov:lanes:... and lanes:hov:... are valid tags. The first is an access tag with the :lanes suffix (i.e. which lanes are allowed for hov) while the second is a lanes tag for a special type of traffic (i.e. how many lanes for hov exist).

There's a page in the Wiki detailing the most common order in keys: osm.wiki/Order_of_key_parts

Please improve your QA procedures. I'm fixing spelling mistakes in keys added by Kaart employees every few days!
There is no "motor_car" key in OSM.

Hi,
you added many "lanes:backward:psv" tags and similar.
The usual key for this is "lanes:psv:backward" (first the vehicle type and then the direction).

Could you have a look and fix this?

Hallo,
was heißt denn "mint_strike"? Dieses Tag gibt es sonst nirgends.

Hi,
you added the new tag "service:fee" in several places - what service does it refer to?

The key is "health_specialty:xxx". (Note the missing 'i' in specialty!)

This variant is already in use many times:
https://taginfo.openstreetmap.org/search?q=health_specialty%3A#keys