Vandalism is intentionally ignoring the consensus norms of the OpenStreetMap community. Simple mistakes and editing errors are not vandalism but may need to be reverted using some of the same tools that are used for vandalism.
Types of vandalism
- Copyright infringement
- Disputes within the OpenStreetMap database (edit wars)
- Disputes on the wiki
- Inappropriate use of Bots
- Persistent disruptive behaviour
Simple mistakes and editing errors are not vandalism, although some may need to be reverted.
The view from a discussion on talk in September 2009 was:
- We should expect that all contributors should at all time attempt to make good, accurate and well researched changes
- We need to ensure that every contributor is on-balance making the dataset better, not worse. If the contribution is in doubt we owe it to other contributors to investigate and respond.
- We should be aware that people make mistakes, need time to learn and newbies often need and will respond to support
- We can request, but not require contributors to add a comments to their changesets and to have created a useful personal page with some details about their interest and knowledge. Doing this makes reversion less likely and make it more likely that the person will be helped if needed.
- In the event that someone seems to be doing strange edits one should initially assume "good faith" but should watch carefully and discuss with others if appropriate.
- If a significant number of edits to ways can be definitively proved to be malicious, obscene, libelous or it is considered that they might bring the project into disrepute then the related change-sets can be reverted immediately without discussion and without 100% checking of the rest of the change-set.
- If the edits are dubious but it can't be proved to be incorrect then we should contact the person and ask for some additional information. If we don't get a reasonable response (or gets no response) and the dubious edits continue and there are not a good number of balancing clearly positive contributions then we should look to prove at least one bad edit and may then come to the decision in discussion with others that it is appropriate to revert the change-set in question and potentially all changesets by that person.
- Once someone has been identified as a problematic contributor then one only needs to perform a brief of inspection of subsequent edits before reversion future changesets.
- If the problem continues then we put them on "virtual ban" where their edits get reverted with no inspection of the merit of the changes unless the person contacts a sys-admin and says they have grown-up and want another chance.
- If someone performs bad edits in any part of the world then they can expect to be a global response because it seems very unlikely that someone would mess with Ireland and do good work in Iceland and I am not sure I would want to work out what was going on in their head - I would prefer to protect the good work of others from mischief that allow good work to be messed on the off-chance that some good edits are also made in amongst the nonsense.
- People who revert other people's work should expect to be able to demonstrate that the reversion was well reasoned and proportionate to the issue.
- Sometimes "null" edits - ones which have no purpose other than to "touch" the element - get made by mistake, by the editor or are useful for updating an area. However, large numbers of "null" edits will be considered disruptive behaviour.
If the extent of the vandalism is local and impact for the overall community is limited then make polite direct human contact via OSM Messaging assuming good intentions and wait for 24-48 hours for a response. If a adequate response is not received then it may be appropriate discuss the issue on an appropriate email list (normally the local, national or regional list) or with trusted individuals. If some edits can be proven to be counterproductive and helpful edits are not obvious then the changesets in question should be reverted.
It may be appropriate to set up a log of reversions. Within England/Wales/Scotland there please put requests on the GB revert request log.
If a significant number of edits to ways can be definitively proved to be malicious, obscene, libelous or it is considered that they might bring the project into disrepute then it is important to respond immediately and revert first and ask questions to the contributor in parallel. It may also be appropriate to contact the Data Working Group at the same time.
Do be aware that it is only possible currently (Aug 09) to revert change-sets where no further edits have been made to the elements.
When a contributor is subject to a "virtual ban" (see notes above) then all their past work may be removed and all new work will be reverted without review until they possibly contact the Data Working Group and request a review of their status.
There are tools available to revert edits for particular change-sets as long as further edits have not subsequently been made to any of the relevant features. These tools are currently hard to use, and require good technical knowledge to operate without causing further damage.
Where possible the local OpenStreetMap community should resolve vandalism through the above processes.
Data Working Group
Main article: Data working group The Data Working Group is authorised by the Foundation to deal with more serious vandalism and reports to the board at the monthly board meetings. In the rare case that the community approach doesn't work the issue should be reported to the data working group (email@example.com).
Moderation mailing list
The Moderation mailing list is used to discuss the development of effective responses to vandalism and mistakes.
There are a number of possible tools and techniques that could be used to manage vandalism issues. Possible tools include:
- White lists
- Data rollback - Let the community run this task using tools that have been tested
- Data deletion - Let the community run this task using tools that have been tested
- Change rollback
- History removal - Requires high level privileges
- Data with later history