As many here will know, osm-revert is a web-based tool that is great for reverting single changesets that are not interlinked with others.
Unfortunately, there have been a number of examples (including one just now) where people try and use it sequentially on a series of changesets, or on one changeset that actually affected data also affected by other changesets.
When that happens what usually results is a mess, and someone who knows what they are doing needs to tidy up.
In order to try and prevent further problems I’ve edited the wiki page for it to suggest that those unfamiliar with the OSM data model ask here first. It’d be great if someone could add a bit more detail as to why it’s a bad idea to use it in certain circumstances - examples would be great.
It’s clearly appropriate to use it in some circumstances, but I don’t think we have got the balance right yet.
Not if you analyse the interdependencies between changesets first, and identify exceptions to be handled separately, no.
(and to answer the other part of the question)
We (the DWG) generally see problems where someone has attempted a revert when they probably should have done something slightly different. These tend to be by people who have less experience of what might go wrong, and they tend to pick the tool with the lowest barrier to entry (which right now is this one). A lifetime ago in OSM, it was the JOSM reverter plugin
The problem isn’t the low barrier to entry, it’s guiding people through the right thought process prior to pressing the button. My all-caps edit to the wiki page is very much a first attempt; that’s why I’m raising it here.
I am missing a warning directly on the osm-revert website, not just in the wiki.
Something like “Reverting changesets is for experts only. If you’re not sure what you’re doing, read the linked wiki page first, or ask others for help”.
I would also like to see it modified so that the two optional fields for comments must have something included in them, which then let’s everybody else know that this CS has already been reverted.
Problems with faulty reverts will continue, until reverts are not possible to do for non revert experts. Even if warning texts are showed or pointed to.
But I hope such restriction will not be implemented. I have done some reverts on my own uploads, but mostly almost immediately after I realised the upload was erroneous. In such cases the possibility of a creating problems is very small. Hopefully I will be able to do such reverts in the future.
I often perform partial revert of minor errors. I don’t want to notify the user about this.
I don’t want to flood the maps.me user’s email with identical messages about the fact that his edits were reverted
Sometimes I revert as follows: I revert changesets, make edits with my hands, and I write to the user a comment that he did incorrectly. I do not want to comment immediately and scare the user.
Maybe make it required by default, but add a checkbox (with some info text) to disable the requirement when checked? Or would that overcomplicate things?
Something like “I really don’t want to create discussion”? I have a feeling that most people would just check that and bypass it.
My general feeling about this issue is that OSM lacks proper built-in monitoring tools, and fixing this lack of monitoring in osm-revert seems like a temporary half-measure. After all, there are other tools people can edit/revert with, and they can also fork osm-revert to remove this artificial requirement completely.
Such monitoring functionality should be built into OSM itself, and is actually something OSM-NG will be working on. As a user, I want to be able to use high-quality monitoring tools on OSM, receive notifications, and configure alerts.
There are too many cases of random vandalism going unnoticed for months.
From the usage reported in the above comments, the requirement could be imposed on full reverts first (While I don’t bother to use partial reverts here, preferring JOSM to check), and excluded on your own changesets. But I suppose these can only be checked after attempting to revert, when fetching the changesets. However if possible, commenting could be required when there are conflicts.
The default option may not be the best to be commenting on all changesets. It can be too annoying with all the emails. This possibly provoke more vandalism or edit wars, if not angry comments and messages. That’'s the biggest concern.
The etiquette I prefer is to comment first before reverting, whether immediately, or after waiting for some days to weeks. Requiring an additional comment only adds to show the changeset has been reverted. Again the same issue, whether the user has already commented on the changeset can only be checked after attempting to revert.
Therefore the question that should be asked first is the intended purpose of commenting. When you become aware of a problem at the object first (as in most imaginable cases), you can already see whether it has been reverted. Better OSM shows the existing status (reverted, restored, deleted, retagged, etc) of objects in changesets. When OSMCha is used, the user should know how to check before reverting.
I have reverted the discussion requirement given the overwhelming community vote against it. Hopefully, one day I’ll be able to satisfy everyone with comprehensive OSM-NG monitoring tools .