Hallo,
es ist nicht meine Absicht, die iD-Hauptentwickler vom Hof zu jagen, sondern sie von den Verpflichten zu entlasten, die sie nicht zur allgemeinen Zufriedenheit erfüllen können.
Wiederholt sind Entscheidungen der iD-Maintainer auf den Mailinglisten Talk und Tagging diskutiert worden. Mehrmals war die Meinungslage auf den Mailinglisten eindeutig (einstimmig oder fast einstimmig). Zwei deutliche Beispiele:
- nonsquare=yes (iD prüft Gebäude auf Orthogonalität, sofern sie nicht mit nonsquare=yes getaggt sind)
- [[OSM-talk] Remove validation rule asking to add highway=footway to railway/public_transport=platform]highway=footway]([OSM-talk] Remove validation rule asking to add highway=footway to railway/public_transport=platform]highway=footway) an railway/public_transport=platform und man_made=pier ergänzen (Begründung der Hauptentwickler: Router müssen dann nicht mehr die implizite Regel implementieren, dass Bahnsteige zum Fußgängerwegenetz gehören): Talk, Tagging
Fast einstimmige Diskussionen auf Mailinglisten sind die Art, wie bei OSM Entscheidungen getroffen werden, wenn nicht abgestimmt wird.
Ich stimme mit vielen Punkten aus dem Eingangsposting überein. Auch mir sind die vielen Alleingänge ein Dorn im Auge.
Die Sache mit dem Fork bringt mich aber ins Grübeln. Ich höre das erste Mal vom “Fork von Frédéric Rodrigo”. Kann einer was dazu sagen?
Wenn ich mich recht entsinne stehen die iD-Hauptentwickler bei einer Firma (war es Mapbox) in Lohn und Brot und bekommen die Aufgabe in ihrer Arbeitszeit an iD zu arbeiten. Und ich finde, generell machen sie einen guten Job, was das angeht. Von den Funktionen hat sich iD enorm weiterentwickelt in den letzten Jahren. Würde an einem Fork auch so intensiv weitergearbeitet werden in der Zukunft? Manch andere OSM-Projekte sind ziemliche Onemanshows und siechen dahin. Ich hätte starke Bauchschmerzen, die Hauptentwickler rauszujagen und zu sagen, es wird schon gehen.
Ich will die Maintainer nicht vollständig entmachten, aber ihre Macht einschränken. Es sind eigentlich Dinge, die mit dem Tagging zu tun haben, bei denen es regelmäßig Krach gibt. Was liegt näher, als sie von dieser Aufgabe zu entlasten?
Der Begriff “Fork” ist unpassend. Die iD-Ausgabe von Frédéric Rodrigo sollte eigentlich “iD Community Consensus Edition” (iD Community-Konsens-Ausgabe) heißen. Es ist ein iD-Editor mit ein paar wenigen Patches. Fork ist nicht der richtige Begriff, es ist ein Softwarepaket, das ein Distributor geringfügig modifiziert. Frédéric hat das geändert, was auf https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions kritisiert wird. Der Quellcode ist unter https://github.com/frodrigo/iD zu finden. Ihr könnt ihn unter http://id.openstreetmap.fr/ nutzen.
Ich schlage vor, seine Ausgabe zu nutzen, bis die Taggingvorlagen und Validatorregeln in unabhängige Projekte unter Community-freundlicher Kontrolle überführt sind. Die Verwendung von Frédérics Ausgae ist eine Übergangslösung. Falls das nicht deutlich genug aus meinem Text hervorgeht, dürft ihr das gerne korrigieren.
Das größte Problem sehe ich darin, einen fertigen Community-ID auf die OSM Hauptseite zu bekommen - das ist wieder Politik.
Dem kann ich nicht widersprechen. Die Herausforderung ist hier, dass die Maintainer der OSM-Hauptseite auf GitHub die iD-Ausgabe wechseln. Ein einfach hingeklatsches Pull-Request wird wahrscheinlich abgelehnt werden. Wenn jedoch nationale Communitys Druck machen, aber erst recht, wenn der Vorstand sie anweist, einen anderen iD zu nutzen, ist ein Wechsel der iD-Ausgabe (oder zumindest kein einfaches Ausrollen neuer Releases der Bryan-Quincy-Ausgabe) zu erwarten. Die Maintainer der Hauptseite wollen niemanden gegen sich aufbringen und so ist es nachvollziehbar, dass sie nicht entscheidungsfreudig sind.
Von daher begrüße ich diese Initiative. Vielleicht sollte man sie gezielt international ausweiten. Soweit ich mitbekommen habe, werden Vorschläge aus Deutschland sowieso nicht gerne aufgenommen, weil “die Deutschen sowieso alles viel zu kompliziert machen”.
Ich möchte jetzt erst einmal wissen, ob mein Vorschlag die Meinung der deutschen Community gut genug abbildet. Ich habe absichtlich nicht direkt den Weg in die englischen Kanäle gewählt, weil mir dort sofort amerikanischer Wind entgegenbläst. Es steht anderen nationalen Communitys (hallo linksrheinischer Nachbar) frei, selbst etwas Ähnliches wie wir zu tun. Wenn sich die Diskussion hier gelegt hat und ich die Änderungsvorschläge eingearbeitet habe, werde ich den Text ins Englische übersetzen.
Zur Erinnerung: Es sind schon weltweite Importe eingestampft worden, weil große nationale Communitys für ihr Gebiet widersprochen haben. Selbst ein gewisser britischer Mapper, der bislang Ja zu jeder Firma in OSM gesagt hat, ist mittlerweile nicht mehr über das Verhalten der iD-Maintainer begeistert.
Meiner Meinung muss das Problem dadurch gelöst werden, dass der OSMF-Vorstand Regeln für Editoren aufstellt. Wenn sich die iD-Maintainer anpassen, ist’s ok. Wenn nicht, muss man die hier geforderten Maßnahmen durchziehen.
Solch einen Vorschlag habe ich zeitweise in Erwägung gezogen, aber aus zwei Gründen verworfen:
- Es betrifft auch alle anderen Editoren und wirkt gegenüber neuen Entwicklern nicht wirklich einladend.
- Die Diskussion solch einer Richtlinie wird sich, wenn es richtig flott geht, über ein halbes Jahr hinziehen, wahrscheinlich dauert es aber eher zwei Jahre. Zwei Jahre, in denen die iD-Maintainer weiter schalten und walten können. Währenddessen werden gewissen Gruppen sich massiv und vermutlich auch erfolgreich dafür einsetzen, die Regeln weichzuspülen. Am Ende haben wir ein Dokument, das eine wirkungslose Absichtserklärung/Selbstverpflichtung ist.
Viele Grüße
Michael