User:Nakaner/Forderungen zur Zukunft von iD

Dies ist ein Entwurf für eine gemeinsame Position der deutschen OSM-Community, über nach Diskussion über die Entwurfsfassung abgestimmt werden soll. Die Diskussion finde an folgenden Stellen statt:

• Forum
• Mailingliste Talk-de

Entwurf: Forderungen zur Zukunft des iD-Editors

Der iD-Editor unverzichtbar, um Neulingen den Einstieg in die Mitarbeit bei OpenStreetMap zu erleichtern. Die Geschehnisse im iD-Projekt auf GitHub und das Gebahren seiner zwei Hauptentwickler erfüllen uns mit großer Unzufriedenheit und Sorge.

Online-Editoren waren und sind für viele erfahrene Mapper ein Ärgernis, weil sie bevorzugt von unerfahrenen und neuen Mappern genutzt werden, die natürlich Fehler machen. Durch die Unerfahrenheit ihrer Nutzer und die Platzierung als Standard-Editor auf www.openstreetmap.org kommt den Hauptentwicklern jedoch eine besondere Verantwortung zu. Der dort angebotene Editor wird vorwiegend von neuen, unerfahrenen Mappern verwendet. Fehler im Editor fallen u.U. später auf, weil die erfahreneren Mapper mehrheitlich JOSM nutzen. Wie bei allen stark verbreiteten Editoren haben gezielte Entscheidungen für oder gegen ein Tag einen großen Einfluss auf die Daten – und das in einem Projekt, in dem regelmäßig sich Tags gegenüber anderen durchsetzen, weil mit Füßen (d.h. Tagnutzung) abgestimmt wird.

In der Tat sind die Ansprüche erfahrener Mapper an Online-Editoren hoch – je nach Sichtweise zu hoch – und Fehler von Neulingen werden gern auch den Entwicklern angelastet. Die älteren Mapper erinnern sich an endlose Threads in Foren und auf Mailinglisten über die Mängel des iD-Editors im Umgang mit Relationen. Diesbezüglich steht der Editor seinem Vorgänger Potlatch in nichts nach und hat es schwer, von erfahrenen Mappern gemocht zu werden.

Die Ankündigung vor einigen Monaten, dass iD einen Validator bekommen solle, haben die Hoffnung geweckt, dass der Editor seiner Aufgabe gerechter wird. Jedoch wurden diese Hoffungen nicht erfüllt. Im Gegenteil, anstatt verantwortungsvoll, vorsichtig und umsichtig typische Benutzer-Fehler zu erkennen und zu vermeiden, nutzen die Hauptentwickler ihre Machtposition schamlos für ihre eigene Agenda aus.

Auch bei den Taggingvorlagen gehen die Hauptentwickler zu forsch vor. Sei es, dass sie sich über den Konsens der auf den dafür etablierten Kommunikationskanälen gefunden wurde, hinwegsetzen, oder dass sie einfach sämtliche vorgetragenen Argumente beiseite wischen, selbst wenn außerhalb der USA die Dinge anders gemappt werden. Die Fälle aufzuzählen, würde den Rahmen dieses Textes sprengen, deshalb sei auf ID/Controversial_Decisions verwiesen.

Wir halten fest:

1. Die Maintainer sind der Meinung, dass das in OSM übliche implizite Tagging (d.h. Standardwerte werden nicht getaggt) durch explizites Tagging (auch Standardwerte werden erfasst) ersetzt gehört. Damit sollen die Daten leichter für Programmierer nutzbar sein. Diese Meinung kann man haben. Es ist jedoch überheblich, diese Meinung mit der ihnen zur Verfügung stehenden Macht durchzusetzen und die Entscheidungen an den etablierten Diskussionskanälen vorbei zu treffen (Beispiel: highway=footway an allen Bahnsteigen und Pieren ergänzen).

2. Sie definieren nach eigenem Gutdünken Tags um und gehen auf Kritik nicht ein. Selbst Kompromissvorschläge anderer werden zurückgewiesen und diesen Leuten Trolling vorgeworfen. Die Diskussion wird durch Sperren einer Github-Isssues abgewürgt und unterdrückt, selbst und erst recht dann, wenn die Maintainer mit ihrer Meinung allein sind.

3. Wiederholt werden herablassende Äußerung über die OSM-Community getätigt. So schreibt Bryan Housel beispielsweise am 23. Mai 2019 (übersetzt, Original unter https://github.com/openstreetmap/iD/issues/6409):

Einige Dinge spielen praktisch keine Rolle bei unserer Entscheidungsfindung:

• wie lange ein Tag mit implizierter Semantik in Verwendung ist
• wie viele Programme (Renderer/Router oder was auch immer) die implizite Regel schon untersützten
• wie häufig das Tag verwendet wird
• was eine Handvoll Leute auf einer meist verschlafene Mailingliste [Tagging/Talk, Anm. d. Übers.] denken
• was eine Person im OSM-Wiki geschrieben hat
• zu wie vielen "-1" ihr die Leute in unserer Issue-Liste abzugeben ermutigt
• was über uns im WeeklyOSM-Klatschmagazin geschrieben wird

Eine Entschuldigung auf der Mailingliste lehnt er ihm Rahmen eines Verhaltenskodexverfahren ab.

Am 29. Mai wiederholt er auf der Mailingliste Talk seine Verachtung über Mailingliste und Teile der OSM-Community (übersetzt):

Wir dürfen „die Community“ nicht als die paar übrig gebliebenen Leute definieren, die noch nicht von dauerhaften Missbrauchstätern und Trollen von den Mailinglisten vertrieben wurden.

4. Die Maintainer sind nicht in der Lage mit Kritik an ihrer Arbeit umzugehen und nehmen diese persönlich. Zu schnell werden kritische Bugreports frühzeitig für weitere Kommentare gesperrt oder eine Mailingliste, wo das eigene Verhalten auf breite, aber sachliche Ablehnung stößt verlassen.

5. Bryan Housel schreibt zwar selbst wiederholt (einmal im Mai 2019, einmal im November) schreibt, dass er keinen Bock mehr auf OSM habe, bleibt aber dennoch Maintainer und führt sein inakzeptables Verhalten fort. Dabei treibt der Keil nur tiefer zwischen den iD und Teile der OSM-Community.

6. Von den Maintainern, zumindest aber von Bryan Housel, werden Vermittlungsversuche Dritter barsch zurückgewiesen.

7. Die Maintainer messen dem Datenschutz nicht die erforderliche Sorgfalt bei. Der iD-Editor lädt Firmenlogos ohne Zustimmung des Nutzers von graph.facebook.com. Auf Bitten, keine Firmenlogos direkt von Facebook-Servern zu laden, wird bissig reagiert und das Ticket schnell mal als "too heated" geschlossen, obwohl selbst die Licensing Working Group festgestellt hat, dass das Verhalten des iD-Editors gegen die DSGVO verstößt.
Das OpenStreetMap-Projekt wird von vielen als die Alternative zu Google Maps wahrgenommen, weil es nicht einem großem Tech-Konzern gehört, dem ein zu großer Datenhunger vorgeworfen wird. Das Abfließen von Nutzerdaten kann daher nicht hingenommen werden. Insbesondere Mapper geben durch ihre Beiträge Teile ihrer Bewegungshistorie preis. Selbst wenn Browser Teile der Information wegfiltern oder – danke Firefox! – das Abfließen unterbinden, es ist ein Tabu. Es ist unserer Außenwirkung in Deutschland und anderen Ländern schädlich, die den USA und Tech-Konzernen kritisch gegenüber eingestellt sind. Das Abfließen dieser Informationen ist von der Licensing Working Group als unzulässig eingestuft worden. Dass die Maintainer einige Tage später dennoch ein Ticket, wo das kritisiert wird, schließen und für weitere Kommentare sperren, zeugt von gnadenloser Ignoranz.

Die Hauptentwickler eines Projekts, die sich selbst Freundlichkeit, Höflichkeit und Inklusivität auf die Fahnen schreiben, sind keinesfalls besser als ihre Gegner. Das Verhalten der Maintainer ist in unseren Augen zu weit über die Grenze des Akzeptablen hinaus. In einer Community, in der auf Sachlichkeit Wert gelegt und wo Sachlichkeit gelebt wird, finden wir derartiges Verhalten, insbesondere das von Bryan Housel völlig inakzeptabel.

Daher fordern wir den Vorstand der OpenStreetMap Foundation zu Folgendem auf:

1. Das Anzeigen von Firmenlogos, die auf Drittanbieterseiten gehostet werden, muss schnellstmöglich unterbunden werden.
2. Die Entscheidung über das Sperren von Benutzern im Repository des iD-Editors und das Sperren von Diskussionssträngen obliegt ab sofort einer unabhängigen Stelle, vorläufig der Engineering Working Group. Wenn die Hauptentwickler mit anderen heftig aneinander geraten, soll sie auf Ersuchen eines Beteiligten moderierend eingreifen, ohne über Sachfragen zu entscheiden.
3. Auf openstreetmap.org die Fassung von Frédéric Rodrigo zum Einsatz, bis die Taggingvorlagen und Validierungsregeln aus dem Editor herausgelöst und als eigenständige Projekte gepflegt werden.
4. Die Betreuung der als separate Projekte gepflegten Taggingvorlagen und Validierungsregeln geschieht nach ihrer Herauslösung aus dem iD-Editor durch ein Komitee, das die Engineering Working Group nach Anhörung der Community auf der Mailinglisten Talk vorerst für ein Jahr ernennt. Das Komitee soll die Vielfalt der Regionen der Welt, in denen OSM-Mitwirkende aktiv sind, in angemessener Weise wiederspiegeln. Gegen Ende dieses Jahres soll evaluiert werden, ob sich das Konzept bewährt hat und ob es angepasst werden soll. Die Maintainer der Kern-Software gehören dem Komitee beratend an, wenn sie das wünschen.