What makes for osm.wiki/Good_changeset_comments (since you did more than described in the comment)

source = ?

Much smaller changeset areas: osm.wiki/Changeset#Geographical_size_of_changesets
When moving to a different area (or starting something unrelated), close the previous set first.

I presume because old_name is more widely supported, and was:* is newer & more-generic for things other than name?

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

P.S. there's also a distinction between convergence & consensus.

I agree with convergence (in principle, as an ideal), but not by force (which includes the tyranny of the majority).

Sometimes converging on the optimal means breaking convention & consensus.

Having rules set in stone inhibits adaptation.

Flexibility in tagging is much more important than the inconvenience of several dozen developers having to implement a little pattern-matching (which they should be doing anyway, for their own reasons).

“Is there a difference between the meaning of service:vehicle:tires and service:vehicle:tyres?”

I don't know, I haven't examined it closely enough. However, in this case (context), probably not.

Personally, I'd opt for tyres (regardless of popularity) because it avoids the possible ambiguity of tires (hence my opening pun: “one tires of enormous changeset bounding boxes”).

Plus, being culturally-British, I'd habitually spell it with a Y.

To argue that something else was proper because it was more common, would be an argument-from-authority fallacy (assuming one cares about rationality & truth; not all do).

“There is consensus on this topic based on the uses (700 for tires vs 2.7k for tyres).”

Depends on your definition of consensus. I agree that tyres has the majority. Where should the threshold be, and who decides (or otherwise how is it decided)?

“There is also consensus to tag the "colour" and not the "color" of roofs, buildings etc.”

Again, I haven't compared. I do know that the presets I use employ colour.

For me (being culturally-British) colour is always spelled with a U.

Yet, even for (*:)colour=* I've encountered (for one context) a (common) value of gray and (in another) grey (also commonly). Makes a slight mockery of things.

Consider, though, that kerb (Yankish) is used instead of curb (British).

I am, in part, playing devil's advocate, here (for good reason, which I'll get to); when presets make it easy to follow (sane, sensible) conventions, then I do so (kerb, sidewalk, street, et alli) (and largely for some of the reasons you hint at).

“abolish widely used tagging schemes as you suggested with your sidewalk vs pavement example”

I wasn't suggesting that it actually be done (besides, changing the text string of a key is not abolishing a scheme; different concepts at different levels of abstraction); I was using hyperbole to make a point. I even indicated a problem with the term pavement (look back to what I said about *:surface=paved).

“I'm only doing it for tags that have the same meaning like in this case.”

Yet, sidewalk & pavement do (as far as I'm aware) refer to the same thing (thus ‘have the same meaning’?).

Broader perspective, for a moment: some of my concern comes from seeing where such zealous thinking leads. Including objectionable changesets (the contributor dismissing objections from many, and citing as justification similar reasons to yours, annoying very many people in the process) & restrictive policies (that inhibit productive work).

I've encountered examples of important details (e.g. if an amenity=charging_station was socket-only or tethered) for which a tagging convention wasn't well established (so I left a note:* to at least capture & preserve the info garnered from survey, for when a good scheme is devised; I could think of a few ways to tag it, but out surveying isn't really the best time for such thinking (especially avoiding bad consequences), nor trying to check taginfo), and of using an obvious tag (rating) to codify relevant data on the info-plate of a street cabinet only to be told that that tag is only for transformers (as if transformers are the only electrical equipment with any kind of rating, which (in reality) is nonsense) because the one saying so was too focused on tagging rules instead of representing reality (which entirely misses the point). Others include changing source(:*)=* tags (when there were multiple sources for values to different keys on the same element) which led to a misleading representation (which I guessed was a case of osm.wiki/Tagging_for_the_renderer again rather than best (least-badly (accurately, ambiguously)) representing reality; all despite my having surveyed the thing, yet he-who-knew-better was far away (and relying on an outdated book)).

All these (notable) examples and I'm one of a few local mappers on a small island (and only contributing for several months so far), nevermind a larger jurisdiction which will see more examples.

I don't disagree with the ideals you express, but it's not that simple.

Other cases which come to mind involve changing the design of the tagging scheme, to fix a clear problem. That's breaking consensus (on use of tagging, if not on the proposed change). That's how separating cuisine=* & diet:*=* came about. Likely others, in the past.

How is anything to ever be improved (by redesign, to fix fundamental (unforeseen) problems with an existing convention?

Would you tell a mechanic to fix your car, but not replace or modify any components?

Unless done en masse (which counts as an automated edit), then trying to do it piecemeal will always face the ‘but that's not what's popular’ objection.

What if consensus is opposed to that which works well or has superior merit? Consensus is a little bit of a cop-out (because it's easier & quicker than proper debate, and settling on any convention tends to have more utility than exactly what that convention is).

Back to the flexibility I mentioned.

Plus, consensus (however that's defined) need not be global; there are national-level differences in conventions. So, data-parsers need to account for this, anyway (besides it being a good idea).

Any wise implementor (of a parser) will know to not expect OSM data to be perfect, and thus won't want his software failing when it isn't. So, using pattern-matching would be done anyway. If there's only ever one match, then nothing is lost, yet the parser remains robust in the face of obvious variations.

Did you consider that maybe a preset is the cause of the different spellings? If not, and that (preset differences) is the case (or presets lacking the key, so people are manually-entering it with their native spelling), then you'll forever be cleaning up the results until the source is fixed.

Turn off the fire-hose (or at least take it outside) before trying to mop the floor and otherwise clean up. Else you'll be doing a lot of mopping indefinitely.

Work smarter, not harder.

What makes for osm.wiki/Good_changeset_comments

A URL alone is meaningless.

“Contradictory and unnecessary information - bridge or tunnel tag has value =no”

Your boundary box includes jurisdictions where no such changes were made.

Worse, it spans the Atlantic, affecting 2 continents. Please make much smaller changeset areas in future: osm.wiki/Changeset#Geographical_size_of_changesets

See comments of changeset/112478786

What makes for osm.wiki/Good_changeset_comments

A URL alone is meaningless.

“Contradictory and unnecessary information - bridge or tunnel tag has value =no”

Your boundary box includes jurisdictions where no such changes were made. Please make smaller changeset areas in future: osm.wiki/Changeset#Geographical_size_of_changesets

One tires of enormous changeset bounding boxes, and renewed arguments over tagging syntax.

It becomes rather stiff, and inflexible.

Can't we have a nice bouncy conversation, which gently rolls along?

“Would they be looking for the key, they'd be pulling in both spellings… I would to ensure maximum capture.”

Because who knows when someone will do a global replace of one variation for another.

m/t[yi]res?/

“In an ideal world there would be only one way to tag something. Unfortunately there are a lot of similar examples (see :color vs :colour keys). It's better to have only one scheme and not bother to maintain two (or more) parallel schemes at the same time. If the current trend continues (which will continue if we don't standardise now) we would have a dozen different tags with the same meaning but with slightly different spelling which is not ideal to say the least.”

No. That's short-sighted. The advantage of textual tagging is flexibility (new tags for new situations, without some long bureaucratic approval process). Only problem is, people come up with different ideas of how to do it.

What you seek is consensus. Good luck getting everyone to agree. Likely each will advocate for their own preference, and the argument is endless.

The problem isn't the keys or valves, but that people are different.

For absolute unification, you'd also have to do s/sidewalk/pavement/ but might that not result in possible ambiguity (pavement:surface=paved (well, of course the pavement is paved; it's not really a pavement otherwise))?

“there's a 17 on the door on the right, now - is that proof enough?”

That it wasn't copied from a proprietary source? No. Entirely irrelevant, and misses the point.

Accuracy of data is one thing. Where the data was sourced from is another.
Hence why surveying is best; it's all (to my non-lawyer understanding) public domain.

My point was about copying from sources which (by default) require permission, but for which permission hasn't been obtained.

When copying someone else's (proprietary) map, the excuse of ‘but that's a reflection of reality so I could've just copied reality’ won't hold. The point being that the source wasn't reality, but someone else's map (which may or may not be accurate).

If sources unencumbered with copyright entanglements are available, then the obvious smart move is to use those.

Bottom line: copying from proprietary sources is (for good reason) against OSM's terms of use. Just like on Wikipedia & other libre projects.

Ignoring such inconveniences doesn't make them moot.

Possibly, else they're misusing StreetComplete for areas they're merely familiar with, rather than actually surveying.

In effect, uploading false / misleading data (by claiming that it's from survey, rather than local knowledge), because they ignored the warnings which SC issues in such cases.

StreetComplete isn't for armchair mapping.

“Maxar imagery and Mapbox Satellite help me with this edit
way/989908342”

Then your changeset comment is incomplete / misleading.

What makes for osm.wiki/Good_changeset_comments

“I realized that I cannot upload such big edits cause it's hard to validate changesets and contradicts osm wiki recommendations.”

The area is one problem, but another is nature / type of changes and the comment=* .

Besides logical separation of unrelated changes into different sets, this better allows the comment to be scoped more precisely.

One set for changing names of ways, another for adding water features (especially to a different area), and the next set for something else.

Even if they're geographically close; different sets for different changes is a good idea. Think of why StreetComplete separates changes by quest-type.

For example, while surveying if I found a street_cabinet and a fire_hydrant on the same corner, since they're unrelated (except by location, which is only a weak association for those two, and may just be coincidence) I would use a separate set for each. This makes very clear which comment relates to which elements. Plus, keeps discussion of one separate from the other; someone else may be interested in infrastructure but not emergency equipment, or the inverse.

However, if updating the tagging (and maybe position) of retailers along the same street, that might make sense to group into a set (rather than one per retailer), since they're related by type & location, and the same kind of change is being made. However, I would still definitely use different sets per-street, rather than the same set for all retailers in a town.

Try to think of how it would be seen in the list of changesets by other mappers. Make it easy for them to decide if they can ignore the set, or want to examine it more closely. When it's ambiguous, then they can't tell without checking each set.

“If you need more information about this changeset you can write to me in DM and i will help you with that.”

It's better to keep it public (hence changeset discussions), for the benefit of everyone. Not just now, but in future.

This also misses the point; there should be sufficient info included when uploading the set, so that other mappers don't need to ask.

This set being ambiguous / dubious is why it's receiving comments from several mappers.

The goal, here, isn't to chastise or make you feel bad (all newbies make some kind of mistake, including those who are now experienced mappers), but to teach & learn, for improvement.

Part of it isn't your fault; the design of some editors is lacking in helping to guide new mappers (see http://github.com/openstreetmap/iD/issues/8590 ). Not that this is an excuse to exhibit poor practices.
Learning good practises is what we're trying to help with. What might come across as annoyance or frustration, isn't because of YOU personally, but that this is a recurring problem (due to lacking design, like I mentioned before).

Globe-spanning changesets will always attract more attention, because they appear in the list of more people monitoring their local area, even if no local changes were made (thus it's noise / spam to most other mappers).

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

source = ?

What makes for osm.wiki/Good_changeset_comments

“could've easily been moved to description/note etc.”

In that case, it sounds like the original changes were osm.wiki/Tagging_for_the_renderer rather than being concerned with data accuracy.

But, then
source = Maxar Premium Imagery (Beta); Mapbox Satellite
which, last I checked, don't show names of ways. So, this changeset is effectively source=null (since imagery_used should specify the referenced imagery).

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

How did you survey several different continents in such a short time?!

Smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

StreetComplete is only for surveying (source=survey), so how did you cross half of Europe in a short span of time?

“StreetComplete is the most effective tool to highlight missing details that I can help fill in — none of the web-based editors I know do that. I'm happy to receive suggestions if any do exist.”

It's one tool, but not the only one. By all means use SC for reference, but edit with something more granular.

Others include:
▪︎OsmBugs (for Android, available via F-Droid) which shows: OSM notes, Osmose, KeepRight, and MapDust
▪︎configuring Vespucci to highlight whatever you regard as problematic
▪︎http://streetcompleteness.haukauntrie.de/ (though at this very moment it seems to be having some technical difficulties)
▪︎osm.wiki/Completeness lists a bunch of resources

Keep in mind that SC only shows pins for pre-programmed quests. Lots more can be added (for which there aren't (yet(?)) quests) with a more generic editor. As the most obvious example, missing features can't be added with SC (or doing anything beyond tagging).

To enhance the map, the best thing would be to survey your local area. Let others do the same for elsewhere. Editing from afar has risks (viz how do you know it hasn't changed since you were last there?).

An important way would be via the ‘check’ quests (‘does … still exist?’), in order to keep more volatile features up-to-date.

“I didn't consider that StreetComplete would bulk-upload changes for different geographical regions in a single changeset”

You implicitly assumed that it would auto-magically handle it. How would it (reliably) determine where to make the split? Why would it need to when it's intended for on-the-ground surveying (and you're limited by, at most, driving distance within a day, but preferably walking distance)?

If you insist, like I said, configure SC to never auto-upload, and then manually sync after finishing one area before starting in another. That'll separate the changes into different sets.

When using a more granular editor, you'll want to set
source = local knowledge
for areas that you know but aren't actually present at.

A desire to enhance the map is fine (I quite relate), but there are good vs. bad ways of going about it. A project of this magnitude has to be structured, lest it become chaos.

I would strongly recommend, for newbies, using SC in your local area. Then examining the changesets it commits to begin learning the clockwork, in order to proficiently use more capable editors (which do less hand-holding).

Even as a contributor who uses Vespucci almost exclusively now, I still have SC running while out surveying, as one of the sources of info on areas that need refinement.