Much smaller changeset areas, please.

See the comments of changeset #111543046 since this changeset has the same problems.

“source=Bing”

Redundant since the changeset is tagged (by iD) with imagery_used=Bing aerial imagery

You should set the value of the source=* tag in the editor as part of the process of submitting changes, not in the comment=*

“Kano city streets and buildings”

Yet, the bounding box spans half of Europe?!

What makes for osm.wiki/Good_changeset_comments

If you want to edit a different area (or otherwise make unrelated changes) than close the current changeset first (in iD press the “Save” button), before you start making other changes.

With large bounding boxes, everyone inside them is notified when checking their local area. Small(er) boxes avoids this.

“the vast variety of sources tags I've seen that are often inaccurate or unclear and the fact that I only made those changes in SC from afar, that I am absolutly certain about, I still think, that in this particular case it doesn't matter”

Wouldn't they make exactly the same argument?

See Moen's Law of Littering: http://linuxmafia.com/~rick/lexicon.html#moenslaw-littering
“People tend to litter where there's already litter.”

Instead, take pride in setting a good example.

Otherwise, well, if none of it matters then why bother at all? Especially if that makes work for others to clean up.

“changes should of course be verifiable by others and the acccurate source tag might help with that.”

Only vandals believe their changes to be inaccurate.
How's anyone else supposed to evaluate the changes of another mapper?

Recent example (I'll even cite the changeset if you like); an account which seems to be of a government employed removed the name=* of a government building. There was no source=* and the comment didn't even mention said removal (let alone why). This all being the account's first changeset. This doesn't inspire confidence. It may have been an unintentional change (which I've seen happen, before).

Citing source=* WILL help. It helps other mappers.

If I, as a surveyor, encounter something which doesn't match reality, and was contributed by an armchair, then I have no qualms about correcting it.
If, however, I saw source=survey, then I'd be more cautious. I'd check more info, and maybe even ask the previous mapper first.

Another (real) example was being unable to find a retailer for which there was a PoI node. No source=*, no contact:*, last-modified years ago.
So, I had no idea what the addition was based on. Maybe it was wrongly tagged (and they meant something else, nearby, for which there might now be a duplicate element). Maybe it really was there, but has since gone. I have no way to judge; only guess. So, I either have to leave it be and wait for an answer from a mapper who stopped contributing years ago (and so may never answer) meanwhile leaving possibly inaccurate data on the map, else I have to change / remove something which I can't find (but may simply have missed; for example I add fire hydrants and more than once had great difficulty locating the plate with relevant metrics, sometimes concluding that it must be missing (and stating so in a note:fire_hydrant), only to then find it after I submit the changes(!))

Other cases have involved info which isn't apparent during survey, but maybe the other mapper got it from a non-survey source which they didn't specify. Should I remove that which I can't verify (yet might be useful), or leave it be (which risks leaving inaccurate / outdated info on the map)?

So, source=* is vitally important, for a whole bunch of reasons.

At the very least, include a note(:*)=* (as a tag), or a comment on the changeset, to indicate the situation, reduce ambiguity, and help future mappers to decide if they can confidently apply their changes or not.

Another reason for setting source=* accurately; I recently discovered that a local mapper had been copying from a source which wasn't obviously public-domain and didn't grant a license (thus is proprietary by default), yet hadn't been specifying source=* at all. This makes all (similar) changesets lacking source=* suspicious, especially given the minefield that is draconian copyright and its trolls.

Same with the government newbie, earlier; why shouldn't I regard the change as a mistake, since I have no reason to think it genuine? Seems that it should be reverted. It's not on me to do his verification work for him (by going there to survey the site).

This, of course, is all on top of how much of a pain in the arse it is to even check the edit history while out surveying. To then discover that some armchair jockey simply couldn't be bothered citing their source.

Another way of characterising the difference (between survey & local knowledge): let's imagine, for a moment, that the relevant resources were unlimited and posed no practical problems with what I'm about to describe. Imagine source=survey as being changes which include photos of what the mapper saw (in order to verify), versus ‘local knowledge’ being far more casual from memory.
Human memory is dubious, yet photos are rather more objective.

The only difference between that, and current practise, is that surveyors are trusted to be truthful and acting in good faith (and if not, then other local contributors would dispute questionable changes, based on their own familiarity (local knowledge)).
Someone claiming their changes are from their memory, rather than inputting the data while on-site, is less reliable. Hence survey is regarded as the highest standard.

If an armchair does well, then it's a whole lot easier for a surveyor to indicate confirmation of accuracy (and spend a lot less time determining what's what). Those cases are a pleasure to survey; I can do a lot more of them per hour than when it's all orphan tags.

Another issue is position: it's often undeclared. It doesn't match GNSS / survey. Sometimes it might match some imagery (which is badly aligned, to start with). You see the problem, I hope.

“In my defense, I wasn’t aware of the tag set by SC”

SC is intended & designed for users to not need to know the clockwork.

However, it has clear warnings against editing anything which hasn't been surveyed. SC is intended for surveying (hence the nature of the questions it asks). These would've had to an dismissed and/or ignored.
Compare: in my defense, Officer, I didn't know that driving through a no-entry would cause a collision. I very much doubt that the cop is gonna be impressed that you ignored the sign saying to not drive along the road in that direction.
Instead of assuming it'll be fine and ignoring it, a better way would be to ask why it's there. If for good reasons then you learn, if for outdated or bad reasons then it may prompt change to improve the situation for everyone (maybe you've found a bug).

You could've seen what it was uploading by examining your own changeset history after uploading quest-answers. There are links to wiki articles about common keys & tag values, to learn more about them.

“In the end I want to help make the map better and more accurate for everyone and not cause additional issues.”

Then diligence. Think of it as a way to convince others to not revert your changes. Imagine editing a wiki without citing any sources to support your changes.

Like with good comments; eventually the other mapper you'll be helping is your future self.

Quality over quantity.

Since this changeset's bounding box spans half the planet, it would've been helpful to specify (in the comment) WHICH Kingdom.

Better still, to have used separate changesets for the distant territories (several smaller boxes, instead of a single enormous one).

When making unrelated changes (as is the case in this set) use separate changesets.

Thus, George-to-Matalan would be one, and (assuming it's even valid) removing the name=* of the Planning offices would be another.

What makes for osm.wiki/Good_changeset_comments since you also removed name=* from way #179975537 (why?).

source= ?

“imagery_used=None”

This is highly unusual for a first edit.

“cmillergovje”

Since that's likely a punctuation-less form of c.miller@gov.je : employees of organisations (including government) are (to my understanding) supposed to gain approval before editing, and not do so as if they're individuals. See the wiki.

Seconding Ale_Zena_IT.

At least the changeset comment was descriptive.

I have to second (third?) the other commenters.

Especially since this changeset is deletion of a couple of ways & a relation.

What makes for osm.wiki/Good_changeset_comments while I'm at it.

“Given that StreetComplete makes it very easy and comfortable to update details, while those changes require a lot of time and effort in Vespucci and other editors, I lean towards accepting that the source might not be 100% accurate in all the cases.”

Convenience doesn't trump accuracy.

Most convenient is to not edit areas for which source=* can't be set accurately (or, in case of SC, which you aren't able to survey). SC gives a warning, when more than some metres from the element, for this very reason.

However, you may simply have to wait a while. I recall reading on GitHub talk of SC setting source conditionally (e.g. based on distance between user & element).

You being willing to accept inaccurate data doesn't mean that it's acceptable for others. One of the differences is that YOU KNOW that it's inaccurate; others have no way of knowing that (given misleading value of source=*).

OSM has a core principle of verifiability. Setting source=survey indicates that you were there (at the time) when you've admitted that you're not.

“I'm not sure if the strict differentiation between "local knowledge" and "survey" is very helpful.”
&
“My point is: what purpose does the differentiation between "local knowledge" and "survey" serve, when it is so hard to define?”

Besides these two sentences being mutually-contradictory; you being unclear on the distinction, or having difficulty defining them, doesn't make that an absolute. That's a logical fallacy; argument from ignorance.

“At what point does a survey become local knowledge? When I have walked a street earlier today and update details about it at home, is it still a survey or already local knowledge? And if I go back to that street and update it while looking at it, is it a survey even though I already knew all the details I was updating?”

That's a much more (intellectually-)honest approach (asking open, non-loaded questions) than making assumptions or holding presuppositions.

I don't (personally) decide such things. I follow the consensus-established conventions described in the wiki. For this matter, see source=*

I have enough experience (generally, rather than of OSM) to know that sometimes there are good but non-obvious reasons behind some rules.

I would invite you to ask such questions in a more prominent place. Such as the mailing lists, or on help.osm.org .

I can only give my own opinion on & interpretation of, the matter.

To me, it's an indication of (un)certainty. Likely stemming from good practise with data-handling, and scientific rigour.

Misleading data will result in mistakes. Sometimes then leading to further mistakes.

Being diligent takes effort, which takes time.
If you're unwilling, then refrain. Leave it for someone else. Drop a note, instead (to draw attention, for locals to address).

I've seen, several times, incorrect assumptions being applied by well-intentioned people.

My point, in general, is that there's then a risk of unknown things going wrong.

But, some specific & practical issues:
▪︎things may have changed since you were last there
▪︎being familiar with an area is different to closely examining it for the purposes of mapping; I perceive & traverse my local area very differently while out surveying than when merely passing through
▪︎one differentiator would seem to be the extent or degree to which the mapper is relying on his own memory (which is generally lousy). Before mobile apps, surveying involved recording in other ways (textual notes, photos, video, audio of the mapper describing what he saw); thus when back home and inputting the data, he's using recorded data rather than his own memory
▪︎a somewhat meta-factor is to know if the timestamp is (at least close to) when the observation was conducted (though there are keys for setting that in an explicit tag)
▪︎in the case of disputes, a survey will always trump mere familiarity with the area; I've encountered things which were wildly wrong when stood there, compared to OSM's data.
▪︎imagine an armchair-mapper finding data which doesn't match imagery; well, if the data is from survey (or a more recent / accurate source), then the latter trumps (I've encountered this one, too)

There are probably more reasons. Though, defying convention will likely need a compelling case. There was obviously a reason why the convention was established.

Consider it good practise. When using Vespucci, I only set source=survey when I'm actually there. If I'm elsewhere (back at base) then I'll set something else.

You may have a point. It may now be something which made more sense in the past. But, don't assume that. Ask the questions in a place that'll be seen by more experienced and/or knowledgable people.

It may be that in the past, before mobile apps, it was acceptable to upload data from a survey done several days prior. That being a limitation of what was possible at the time.

However, now, maybe the definitions can be more strict. Instead of source=survey meaning that you WERE there, now it soulful mean that you ARE there (at least when inputting the data (or answering quests in SC), to allow for uploads delayed by a few hours when the user has a suitable connection again (I say that as one who has often done a day of surveying with SC and uploaded everything via 802.11 when back at base)).

In one of the scenarios you're hinting at, maybe it could be solved by setting a tag stating when the data was collected / input, as distinct from when the changeset was opened / closed.

Personally, the temporal threshold between survey & local knowledge would be 24 hours (though I could be persuaded to reduce that).

Then source=survey is very misleading.

Based on what you've said, source = local knowledge would be more accurate.

Since StreetComplete is all about surveying, use an editor (like Vespucci, which I notice you've used before) which allows you to set the value of source=* .

As for changeset bounding boxes; SC is for surveying, like I said. If, however, some playboy was jetting around the world, then the smart thing would be to have SC upload quest answers before surveying a new area.

To avoid globe-spanning changeset bounding-boxes, which spams the local list of many people, it is much better to keep the area covered by a set of changes small. If you wish to edit many areas, use separate changesets.

You surveyed both sides of the Atlantic in the same day?

Seeking review especially on opening_hours . Unsure if syntax is (in)valid or if I may have found another editor bug.

“As I'm a newbie, I wasn't aware of any of those points.”

Indeed, quite understandable. I didn't mean to imply blame.

It's becoming increasingly clear that the problem isn't the newbies, but poor design of editors in this regard (usability / interaction-design, lacking tutorial). Hence pointing to the GH issue; it's a known problem, and is at least receiving attention.

Actually, I cited this changeset there, as clear evidence of the need for a remedy. So, you actually helped with making the compelling case by articulating the failure / cause clearly (and, based on your contribution history, you're exactly the target user-group). So, thanks 🙂.

“I didn't know that it was important to seperate them though.”

Relevant GitHub issue: http://github.com/openstreetmap/iD/issues/8590# Add feature to reduce number of unintentional huge-area or even globe-spanning edits?

“Is there a way to undo and reorganize the changes?”

No. Not without generating more changesets, which wouldn't roll-back changes but simply increment the version number of affected elements. This changeset would remain, regardless.

“I will pay more attention to the scope of future commits.”

Many folks will appreciate that.

To explain some context. Besides the principle of grouping (into sets) related changes, and by extension unrelated changes being part of different changesets, as a matter of good housekeeping, there are many practical reasons. They include:
▪︎large bounding boxes result in notifying all the people monitoring their local area for changes, who are within the bounding box. When said bounding box covers half the planet, that's spamming an awful lot of people's local list. Tools to filter changesets can only do so much to combat this problem.
▪︎large changesets are more difficult to review & verify (given that OSM is all about mapping what's verifiable on-the-ground)
▪︎it's difficult to make clear & accurate changeset comments (see osm.wiki/Good_changeset_comments ) with a lot of (unrelated) changes, in comparison to changesets separated by geographic region or topic. A specific problem with huge sets is that a commenter has to first identify the element to which they're referring (amid the many pages of them, or spanning such a large area that the individual elements are not all visible together) before being able to comment about it. Small & local changes are much more obvious (e.g. there's only 1 of a given type of element) re context of comments

I'm sure that there are other practical reasons, but I'm drawing a blank at the moment.

👍 thanks.

The whole réservoir area / site needs a bunch of surveying attention, and is on my hit-list.

Apologies; only just noticed your reply.

Good point. My mistake for not actually checking what was changed, and being hasty with commenting (on faulty assumptions, in this case).

Unfortunately my local changeset list is flooded with carelessly large-area changesets. This is one of the rare unavoidable exceptions.

I'll try to avoid remarking on non-careless large-area changesets in future 🙂.

I find this bot outputs excessive changesets (which pollutes the changeset list, and is annoying), and somewhat pointless in general (I can expand on the technical reasoning if the bot's author would like).

However, in this instance, it actually did something useful, and fixed an actual problem (transforming a mere hostname into a fully-qualified URL).

Having briefly checked your recent changesets, whatever configuration / usage changes you've made have had the desired effect; very small changeset areas.

Excellent 🙂👍. Continue, good sir.

Thankyou for your contributions. (And for reducing the noise (of irrelevant changesets) in my local list.)