Lee Carré (2021-06-17 01:08:01+00:00): @SekeRob

“ID editor has a colour changing counter right top. When turning Orange certainly time to switch to comments, fix any flagged issue[s] and save.”

Ah, I know exactly what you're describing (having never used iD); Vespucci has a similar feature. Good to know.

I had never thought about it in this context; I imagined that it was for the benefit of the systems, to avoid uploading an enormous amount in one go (rather than spreading the (e.g. re-rendering) load over time).

Apparently, newbies ignore the warning colours. Sigh.

“For self it makes the resolutions manageble. Allows a quicker review then [j]ust start a new one if not done.”

I make a point and/or habit of avoiding that in the first place. I (try to) keep my changesets semantic & containing changes related to each element. Examples:
* (all) shops in the same market
* various PoIs along the same stretch of road or in the same building
* a particular site (e.g. a hotel resort, or hospital)
* all benches in a park
* if they do span a non-tiny area, then the elements are all of the same type (e.g. the tagging of multi-storey carparks, or public parks; sort of like how StreetComplete groups quests by type when uploading changes; one changeset for each quest type)
* sometimes, I'll make very small changesets, such as for adding an electricity substation / transformer I've happened upon; I don't know when I'll find the next (given the 2 hour limit on keeping a changeset open), and they tend to be spaced apart. Several small(er) changesets doesn't seem to raise any objections.

This way, I tend to leave unrelated things for another (possibly the next) changeset, since they'd be outside the scope of the current set.

This also makes it easier for anyone wishing to comment on a changeset. Firstly I hope that the set is easier to comprehend in the first place (as opposed to appearing an assortment of random edits), and because the scope is already inherently limited. They don't have to start by stating which element they're commenting about; it should be obvious from context, even with only a brief mention of the common name of it.

Plus, for my own future benefit, based on experience. It's already served me well (when I had to find the ID of a node a had to undelete; descriptive comments meant that I didn't need to inspect every changeset, which greatly reduced the time spent finding the right set). It's then almost like a personal (descriptive) log of what I've done.

But, then, I see commit comments as a valuable asset, rather than some pesky thing to satisfy in order to submit my changes. In future, the context which may have seemed obvious at the time, won't be once the task is stale. Comments are forever, so best make them good.

Though, in thinking about it, while out surveying I'm limited in how much I can reliably change (per hour, or however one wishes to measure) by my walking-rate. So, this probably also keeps things in check, compared to panning across the globe and adding whatever, wherever from various data sources (imagery, notes, and whatever else armchair-mappers use).

Re verbosity of comments; when the scope is limited, I find that it's acceptable to give less than a blow-by-blow description in the comment.
Many of mine are along the lines of ‘updated (tagging) [place] at [address]’. If it's only a few changes, then I'll specify them. Otherwise it seems excessive. The details are in the changeset itself.
Whereas, with a large changeset, this wouldn't really work (and probably explains some of the very vague comments we see in the list of recent changes).