Id: Don't propose automatic edits to unexperienced users

[dieterdreist]

From previous interactions with you, and from my experience in OSM, iD is the go to editor for unexperienced users. This does not imply there aren't pro-users who also use it, but the vast majority of new users as well as the occasional contributors, are using iD.
iD is also an editor who puts less emphasis on how tags are actually named (after all, the mapper doesn't even see tags unless she specifically requests it).
As a consequence, most users of iD editor will not have the necessary knowledge to judge which tag is appropriate, and we should not burden them with decisions about tagging.
I believe we should not propose automatic retagging suggestions to most users of iD, simply because they lack the requirements to adequately respond to them.

[BjornRasmussen]

iD asking all users to upgrade tags is, in my opinion, very productive, and has started to significantly improve data quality in many places I map, and I don't think that stopping newer mappers from improving data quality is a good idea.
As for the automated edit issue, the reason so many people (myself included) question bot edits is that those edits just convert bad data to a better format without noticing when those edits are incorrect. They also gives a false sense of data freshness. So basically, it's not "automated editing" that's the problem, it's those negative issues we associate with it.
iD strikes a good balance, where the upgrades improve data automatically, not _autonomously_, and those changes are visible to a human. If a pond is mapped as amenity=swimming_pool, a human would not just accept iD upgrading that to leisure=swimming_pool like an autonomous bot would. Also, data freshness is no longer a problem, because those edits really only happened when someone was editing the object anyway. The disadvantages of bots, or at least those I know of, are bypassed by the way iD helps mappers contribute.

In your argument, you stated that automated edits are bad, and that new users shouldn't have to worry about tagging. With iD, neither of those are currently a problem. Tag upgrades now have manual review through visual feedback, so new users don't _need_ to know about tags to see when something is wrong.

My opinion on this is from _my experiences_, though, and I can't possibly know every issue iD could possibly be causing. Could you give some links to changesets where, in your opinion, the current behavior of iD caused data quality problems?

[matkoniecz]

If a pond is mapped as amenity=swimming_pool, a human would not just accept iD upgrading that to leisure=swimming_pool like an autonomous bot would.

I am not sure, given that iD has "upgrade tags" as sole description of edit. Maybe iD editors are more likely to make an additional edit after clicking "upgrade tags".

Yes, tags that will be edited can be shown but it is hidden by default and it is not clear especially for newbies.

Tag upgrades now have manual review through visual feedback

I wanted to test it, but https://preview.ideditor.com/ is down and shows 403 Forbidden. Is there some screenshot how it works?

[dieterdreist]

actually, my point is, even if it would be shown by default which modifications will be performed, it would not change much, because, according to the concept of iD, users _should_ not have to care about tags (and are usually not brought in contact with tags, unless they explicitly desire so).
This is where I see a contradiction: let users decide about tagging specifics and confirm automatically proposed edits for all the area they have loaded into the editor, and on the other hand state they should not have to know about tags.

[quincylvania]

@dieterdreist Thanks for your feedback.

This does not imply there aren't pro-users who also use it, but the vast majority of new users as well as the occasional contributors, are using iD.

Yes, out goal with iD is to make mapping accessible to as many people as possible, particularly new and non-technical users.

iD is also an editor who puts less emphasis on how tags are actually named (after all, the mapper doesn't even see tags unless she specifically requests it).

Exactly. Mappers shouldn't have to know anything about tagging to easily and successfully add useful data with iD. Roughly 6 in 7 people don't even speak English, so showing them the tags is pointless.

I believe we should not propose automatic retagging suggestions to most users of iD, simply because they lack the requirements to adequately respond to them.

iD's tag upgrade system exists exactly so inexperienced users can put data in a standard format without needing to spend hours on the wiki researching tags. This is the same reason iD has presets and fields. We can argue about specific tag upgrade paths, but limiting this feature to "experienced", English-speaking users is exclusionary and we're not going to do it. How would we even determine who meets these arbitrary "requirements"?

And to be clear, iD does not enable automated edits. Changes are made manually on a feature-by-feature basis. Users can tell if the upgrade worked as expected without viewing the tags at all, and instead looking at the preset name, icon, fields, and map rendering.

[quincylvania]

I wanted to test it, but https://preview.ideditor.com/ is down and shows 403 Forbidden.

@matkoniecz You have to add the branch you want to view at the end of the URL, like https://preview.ideditor.com/master.

[BjornRasmussen]

Tag upgrades now have manual review through visual feedback

I wanted to test it, but https://preview.ideditor.com/ is down and shows 403 Forbidden. Is there some screenshot how it works?

Sorry for the bad wording there. What I meant is that now with the validation suggested upgrades, the users are in control of the updates, and for the most part get to see the changes made without understanding tags.

[dieterdreist]

And to be clear, iD does not enable automated edits. Changes are made manually on a feature-by-feature basis. Users can tell if the upgrade worked as expected without viewing the tags at all, and instead looking at the preset name, icon, fields, and map rendering.

IMHO this is a tautological circle: iD defines which tag means which preset, mapper is asked to automatically change tags so that they fit into current iD presets, mapper verifies with current presets and can "verify" that the tags he set are corresponding with iD's idea of what they mean.

It would work if there was only iD, but it doesn't work in a pluralistic system, where meaning of tags is mostly defined through common agreement about their applicable usage and their significance is defined through usage numbers.
The existence of presets alone is already a major distortion of this system, but batch changing tags is clearly what was tried to prevent with the semi-automated editing guideline.

[quincylvania]

It would work if there was only iD, but it doesn't work in a pluralistic system, where meaning of tags is mostly defined through common agreement about their applicable usage and their significance is defined through usage numbers.

iD's tags _are_ "mostly defined through common agreement about their applicable usage and their significance is defined through usage numbers". iD contains logic for thousands of tags and only a few are ever criticized. Some of those are mistakes and the rest are the result of tough decisions when OSM standards are inconsistent. We really don't care that much about tags.

The existence of presets alone is already a major distortion of this system

This is where we seem to have a fundamental disagreement about the nature of the project. The point of iD is to be an easy-to-use editor for non-experts. That simply doesn't work if we expect people to type in all the tags by hand.

but batch changing tags is clearly what was tried to prevent with the semi-automated editing guideline.

Yep, this is how I interpret the guidelines as well.

[dieterdreist]

iD's tags are "mostly defined through common agreement about their applicable usage and their significance is defined through usage numbers". iD contains logic for thousands of tags and only a few are ever criticized.

yes, I completely agree with you, what people are asking from you is that _all_ of the tags you set in presets would be commonly agreed and established.

Some of those are mistakes and the rest are the result of tough decisions when OSM standards are inconsistent.

Agreed everybody makes mistakes (the more eyes are on something before released to public, the less probable they are), that's not the question.
IMHO (and I believe this is the common understanding) you should not make these tough decisions. When standards are inconsistent, I would wish you refrained from adding anything for it. In the past, some inconsistencies have also been introduced by iD, but I take your word, you will take care in the future to strive for not repeating these mistakes.

We really don't care that much about tags.

IMHO, tags are really important, because all there is on a data level is geometry and tags, and all we have to interpret the geometry are the tags (if we don't know an area).

The existence of presets alone is already a major distortion of this system

This is where we seem to have a fundamental disagreement about the nature of the project. The point of iD is to be an easy-to-use editor for non-experts. That simply doesn't work if we expect people to type in all the tags by hand.

Yes, I understand the concept, and I support it, as we cannot ask from the occasional contributor to learn a tagging language just to make a few contributions (and many contributors do not speak English). But at the same time, we should also be aware that they are indeed a major distortion of the system, and give developers and translators (or whoever is in charge of deciding on the content of these presets) tremendous power (and potentially, points of failure). When there are inconsistencies in the tagging, there may be reasons for them. OSM is a global project. Nobody can know all cultural context and tag usage. Inconsistencies in the tagging system should lead to a community discourse so they can be solved.