DE:Vandalismus
Vandalismus bezeichnet die absichtliche Missachtung der vereinbarten Normen der OpenStreetMap Community. Einfache Fehler und Fehler beim Editieren sind kein Vandalismus, müssen aber möglicherweise mit den selben Werkzeugen rückgängig gemacht werden, die auch für Vandalismus eingesetzt werden.
Vandalismus und andere Arten schlechten Mappings
Vandalismus wäre, wenn man es wortwörtlich nehmen würde, Graffiti (Kritzeleien) auf der Karte, geleitet von der Motivation kindischer Scherzhaftigkeit oder dem bewussten Versuch, dem OpenstreetMap-Projekt zu schaden. Reiner Vandalismus geschieht relativ selten. Das OpenStreetMap-Projekt ist ein Projekt für die gute Sache und die Geodaten "gehören" der Community. Im Großen und Ganzen wird das respektiert.
Es gibt mehrere Arten von schlechtem Mapping, welche Vandalismus ähneln. Ihnen liegen verschiedene Motivationen zugrunde, die zwar kein kindischer Spaß sind, aber Abhilfemaßnahmen desselben Typs bedürfen. Dazu gehören unter anderem:
- Copyright-Verletzung
- Streitigkeiten innerhalb der OpenStreetMap Datenbank (Editwars)
- Streitigkeiten innerhalb des Wiki
- Zweckwidriger Einsatz von Bots
- massenhaftes Ändern von Daten (z.B. Ergänzen oder Ändern von Tags)
- beständiges störendes Verhalten
- Spamming
- absichtliches Entfernen von Daten, die als korrekt bekannt sind
- undiskutierte Importe
Einfache Fehler und Bearbeitungsfehler sind kein Vandalsimus, auch wenn einige dieser Fehler rückgängig gemacht werden müssen.
Reaktion auf Vandalismus
Allgemeine Richtlinien
Dieses Thema wurde im September 2009 diskutiert ([1]). Folgende Aussagen wurden gemacht (aus dem englischen Original übersetzt):
- Wir sollten davon ausgehen, dass jeder Mitarbeiter zu jeder Zeit gültige, genaue und gut recherchierte Änderung vornimmt.
- Wir sollten sicherstellen, dass jeder Mitarbeiter insgesamt die Datenbank verbessert, nicht verschlechtert. Wenn eine Mitarbeit zweifelhaft ist, schulden wir es anderen Mitarbeitern diese zu untersuchen und zu reagieren.
- Wir sollten uns bewusst sein, dass Menschen Fehler machen, Zeit zum Lernen benötigen und Neulinge häufig Unterstützung benötigen.
- Wir können Mitarbeiter auffordern aber nicht zwingen, Kommentare zu ihren Änderungssätzen hinzuzufügen und eine hilfreiche Benutzerseite mit Details über ihre Interessen und Kenntnisse anzulegen. Macht man das, ist eine Reversion weniger wahrscheinlich, jedoch wahrscheinlich, dass der Person geholfen wird, wenn nötig.
- Im Falle, dass jemand merkwürdige Änderungen vornimmt, sollte man vorerst von guten Absichten ausgehen, allerdings sollten diese Änderungen sorgfälltig beobachtet werden und bei Bedarf mit anderen diskutiert werden.
- Wenn für eine große Zahl von Änderungen an Ways bewiesen werden kann, dass sie böswillig, obszön, beleidigend sind oder das Projekt in Verruf bringen könnte, dann können die betroffenen Changesets rückgängig gemacht werden ohne dass 100% der übrigen Änderungen überprüft werden müssen.
- Wenn Änderungen zweifelhaft sind, es aber nicht bewiesen werden kann, dass sie falsch sind, dann sollten wir die Person kontaktieren und nach weiteren Informationen fragen. Wenn wir keine befriedigende Antwort (oder gar keine Antwort) erhalten, die zweifelhaften Änderungen fortgeführt und nicht genügend ausgleichende, gute Änderungen vorgenommen werden, sollten wir versuchen mindestens eine schlechte Änderung zu beweisen, um, in Absprache mit anderen, die Entscheideung zu treffen, dass es angemessen ist, die fraglichen Änderungen und möglicherweise sämtliche Änderungen dieser Person rückgängig zu machen.
- Sobald jemand als problematischer Mitarbeiter identifiziert wurde, so muss nur eine kurze Überprüfung späterer Änderungen durchgeführt werden, um auch zukünftige Änderungen rückgängig machen zu können.
- Sollte das Problem fortbestehen, so wird dieser auf 'virtual ban' gesetzt, wobei dessen Änderungen ohne Überprüfung rückgängig gemacht werden, es sei denn diese Person wendet sich an einen sys-admin und sagt er sei erwachsen geworden und wolle noch eine Chance.
- Wenn jemand schlechte Änderungen in einigen Teilen der Welt durchführt, kann er eine globale Antwort erwarten. Denn es erscheint als überaus unwahrscheinlich, dass jemand Irland durcheinander bringt, aber in Island gute Arbeit macht. Ich bevorzuge es, die gute Arbeit anderer vor Unfug, der diese gute Arbeit durcheinander bringt, zu schützen, auch wenn die Chance besteht, dass in dem Blödsinn einige gute Änderungen enthalten sind.
- Leute, die die Arbeit anderer rückgängig machen, sollten erwarten, dass sie in der Lage sein müssen, dass diese Reversion gut begründet und dem Fall angemessen war.
- Manchmal entstehen 'null'-Änderungen - solche, die keinen anderen Zweck haben, als ein Element zu berühren - durch Benutzerfehler oder sind hilfreich, um ein Gebiet zu aktualisieren. Trotzdem werden große Mengen solcher 'null'-Änderungen als störend angesehen.
Normale Reversion
Sollte das Ausmaß des Vandalismus lokal und die Auswirkung auf die gesamte Community begrenzt sein, so sollte unter Annahme guter Absichten via OSM Messaging ein direkter, höflicher Kontakt zum Urheber hergestellt werden. Sollte innerhalb einer Frist von 24 bis 48 Stunden keine angemessene Antwort erfolgen, so sollte das Problem in einer entsprechenden E-Mail-Liste (üblicherweise der lokalen, regionalen oder nationalen Liste) oder einer vertrauten anderen Person besprochen werden. Sollten Änderungen nachweislich kontraproduktiv und keine klar erkennbaren hilfreichen Änderungen vorhanden sein, so sollten die betroffenen Changesets rückgängig gemacht werden.
Schnelle Reversion
Wenn eine große Zahl von Änderungen nachweislich bösartig, obszön, beleidigend sind oder diese das Projekt in Misskredit bringen könnten, ist es wichtig, unverzüglich zu reagieren und zuerst diese Änderungen rückgängig zu machen, und parallel eine Nachfrage an den Urheber zu stellen. Außerdem kann es angemessen sein, gleichzeitig die Data Working Group zu kontaktieren.
Es ist zu beachten, dass (Stand August 2009) nur solche Changesets rückgängig gemacht werden können, deren Elemente nicht weiter bearbeitet wurden.
Virtual Ban
Wenn ein Mitarbeiter in den Zustand 'Virtual Ban' versetzt wird, so werden alle seine vergangenen Arbeiten gelöscht und zukünftige Arbeiten automatisch rückgängig gemacht, solange bis dieser kontakt zur Data Working Group aufnimmt und eine Neubewertung seines Status beantragt.
Tools und Links
Es stehen Werkzeuge zur Verfügung, mit denen Änderungen rückgängig gemacht werden können, sofern keine weiteren Änderungen an den betreffenden Elementen vorgenommen wurden. Diese Werkzeuge sind aktuell schwer zu nutzen und erfordern gute technische Kenntnisse, damit weiterer Schaden vermieden wird.
Steuerung
Soweit möglich, sollte die lokale OpenStreetMap Community Fälle von Vandalismus durch oben genannte Abläufe lösen.
Data Working Group
- Hauptartikel: DE:Data working group
Die Data Working Group ist durch die OpenStreetMap Foundation autorisiert, schwerere Fälle von Vandalismus zu bearbeiten und erstattet darüber in den monatlichen Board Meetings Report. In den seltenen Fällen, in denen die Vorgehensweise der Community nicht funktioniert, sollte die entsprechenden Fälle an die Data Working Group gemeldet werden (data@osmfoundation.org).
Entwicklung
Es existiert eine Reihe von Werkzeugen und Techniken zur Verwaltung von Fällen von Vandalismus:
- 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
- Rollbacks
- Data with later history
