Change requests instead of direct changes

[slhh]

When detecting any potential breakage iD does only have two options currently:

• prevent the contribution
• accept the breakage

Both options are quite bad. In such cases iD should have a third option to store a change request without affecting the data which is considered as the current state of the database. The change request should be reviewed/improved by a more advanced user before applying it.
In order to reduce review requirements iD should separate independent, non-breaking parts of the changes into a direct changeset.

This issue is a hard one, but we should think about it, because the benefit could be big.

For example this can be a solution for the large feature issue #3681 .

[bhousel]

Wouldn't other things need to be built into OSM to make this work?

If I'm understanding your suggestion, instead of "Save my changes to OSM" you want to add an option like "Submit these changes into a review queue". Presumably OSM would have people who watch over this review queue and approve things quickly before the changes get stale and introduce version conflicts.

[slhh]

Presumably OSM would have people who watch over this review queue and approve things quickly before the changes get stale and introduce version conflicts.

This seems to be the simplest variant. We would need a database service for the review queue, but I don't see a requirement to integrate it into OSM. Loading from the queue server into a new JOSM Layer seems to be easy, just loading from Overpass Turbo. I don't believe in iD as a review and rework tool, especially due to focussing on changes including some breakage. An open question would be how to save the reviewed changeset. In case of saving to OSM directly from JOSM, it would be considered as a contribution of the reviewer. Maybe a little plugin can change this behavior. Maybe the changes can be passed through the queue server, but occuring conflicts can be an issue in this case.

Edit: Conflicts with subsequent edits of the same user seem to be very likely due to the review queue. It is much more likely that the same objects are edited by the same user again than by another user editing in the same place. I don't have a solution for it yet. So let's think about different approches for the main issue too.

[slhh]

Second approch:

1. Separate critical and non-critical changes into different changesets and mark the critical one (use changeset tag) or the contained objects (use normal tag) as to be reviewed. The method using a changeset tag seems to be the prefered one, in case this doesn't generate major problems.
2. Set a slave database up, which is updated from the main database, but the critical changesets are not applied before review or a timeout. This will likely require to delay some dependent changesets too.
   The breakage brought into the main database would be mostly filtered out this way, provided we have a sufficiently active community reviewing the changes. The slave database has to feed most OSM applications, while OSM maintainace tools are likely to be feed more directly from the main database.
3. For the review I see two different methods depending on how we mark the critical changes:

• Using changeset tags the review process can be based on maproulette. The review status has also be tracked by maproulette and this status should be provided to the slave database update process, because we can't rewrite the changeset tag later, at least not without API change. Maybe adding a changeset comment with some specific content can also be used to indicate that the review has been done.
• Using normal tags on the objects the review process can scheduled based on Overpass Turbo. A completed review has to be acknoledged by clearing the tags marking the objects as to be reviewed, which would be required anyway.

[bhousel]

Ok, If you can get some momentum from the OSM community behind this, I'll implement it. Until then, it's not clear that anybody actually wants this, so let's leave it closed.