[Entwurf] Gemeinsame Position zur Zukunft des iD-Editors

Darf man sich outen - ohne aufgespiest zu werden?

ID ist so erfrischend einfach, wenn man einfach mappen will. Die Spezialschluessel sieht man nur, wenn man hinguckt. Wenn man sich nicht jedesmal in detailversessene Mappingaktivitäten einlesen will, gibt der Editor erfrischende Vereinfachungen her.

Beispiel: Auf dem Weg ist eine Schranke. Man sucht in ID nach Schranke und setzt den Punkt. Dann wird man noch gefragt, wer da durch darf. Nicht mehr.

Bei JOSM hat man ständig den Eindruck, man muesste noch definieren, ob die Schranke nach oben oder zu Seite öffnet (lift_gate, swing_gate), aus welchem Material der Schlagbaum besteht und soweiter und soweiter.

Zumindest ich verbrauche da jedesmal sehr viel Energie - denn auch das Entscheiden, etwas nicht zu mappen, ist ja eine aktive Entscheidung.

Und ehrlich gesagt ich wuensche mir mehr davon - nicht weniger. ich will einen Bach in die Karte eintragen können und den auch ueber eine Strasse ziehen wo ein intelegientes Programm nicht davon ausgeht, dass Strassen normalerweise von Bächen ueberschwemmt sind, sondern klar ist, dass die irgendwie ueberbrueckt werden - und nur in Spezialfällen abfragt, ob das anders ist.

ich will ein Waldgebiet an einem See vorbeifuehren können und ein intelligentens Programm haben, dass weis, dass normalerweise in Seen kein Wald wächst - und nur in Spezialfällen das anders getaggt werden kann.

Und diese Beispielsreihe kann ich weiter fortsetzen.

Dass das nur geht, wenn den Entwicklern die Möglichkeit gegeben wird, die Usuability vor die Taggingreligion zu setzen, ist doch klar. Dass das am besten in einem gut moderierten Prozess geschieht, sollte genauso klar sein.

Das die Gruppen, die sich speziell fuers Tagging interessieren, allerdings nicht die einzige Referenzgruppe sein kann ist auch klar.

Verbleibt bei mir das komisch Gefuehl, etwas zu mögen, was durchaus seine problematischen Seiten hat.

@tox-rox Weg eines Goldstandartes finde ich, wenn man gleichzeitig nach radikalen Vereinfachungsmöglichkeiten sucht, sehr vielversprechend.

Um wieder auf das Beispiel zu kommen: Fuer mich ist eine Schranke an einem Waldweg vorallem ein Hinderniss fuer bestimmte Nutzungsarten. Mir fällt keine Anwendung ein, wo es fuer mich wichtig sein könnte, zu wissen wie sie öffnet. Und dass ID hier mir eine einfache Möglichkeit gibt, mich nicht drum zu kuemmern ist toll. Denn die Nutzer alleine mit der Frage “was mache ich denn, wenn mir das egal ist” zu lassen, ist auch nicht gerade gut. Mir ist schon klar, dass ich durch ID jetzt massenweise eigentlich “falsche” Einträge in die Datenbank schreibe (Schranke gibt es ja nicht ohne Details). Aber die Usability rechtfertigt auch irgendwann solche Vereinfachungen.

Die Posts von woodpeck + Nakaner bestehen größtenteils aus (durchaus begründeter) Kritik an den Maintainern selbst, verknüpft mit der Forderung nach einem Fork.

Also nochmal ganz klar: Absicht von woodpeck + Nakaner ist es, die iD-Maintainer loszuwerden.

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.

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:

Fast einstimmige Diskussionen auf Mailinglisten sind die Art, wie bei OSM Entscheidungen getroffen werden, wenn nicht abgestimmt wird.

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.

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.

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. :roll_eyes:

Solch einen Vorschlag habe ich zeitweise in Erwägung gezogen, aber aus zwei Gründen verworfen:

  1. Es betrifft auch alle anderen Editoren und wirkt gegenüber neuen Entwicklern nicht wirklich einladend.
  2. 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

… was mich ja mal zu einer Bemerkung provoziert hatte, dass sie dabei ihre journalistischen Standards gefährdet.

Bryan’s Punkt ist doch, dass die Diskussionskanäle der “Community” von Trollen gekapert sind und er an solchen Diskussionen kein Interesse hat.

Darauf muss man doch auch mal eingehen und hier nicht schon wieder das Bild zeichnen, es gäbe hier “die community” und da die paar Querulanten.

Es ist halt schwierig, und dass es nicht “den Mapping Standard” gibt, weder im Wiki noch sonstwo, ist ein Ausdruck davon, und daran könnte man doch ganz unabhäbgig mal arbeiten, ohne sich jetzt willkürlich paar Sündenböcke rauszupicken.

Forderungen nach einem Branch-Wechsel für ID auf der Hauptseite sollten nur Leute stellen, die sowas selber online haben und glaubhaft machen, dass das mehr als ein Eintagsfliege ist.

Das an sichselbst ist nicht verkehrt. Sicher als userinterface für Leute die sich nicht in JOSM reintaufen möchten. Das Problem erscheint wenn der Editor dan z.B. alle diese Tags ohne weiteres auf das Objekt setzt, ohne rücksicht zu nehmen auf welche Tags als standard gesehen werden oder nicht.

Eine Schranke wäre vielleicht nicht der beste Beispiel, aber wenn der Benutzer mit iD einen road=unclassfied zufügt, dann angibt das eigentlich jeder den benutzen darf und iD dann den ganzen motz an foot=yes, bicycle=yes, motor_vehicle=yes usw. auch auf das Objekt setzt, dann ist das nicht wie es sein soll. Das ist überflüssig und leitet bloß zu mehr daten die runter geladen und z.B. von routern ausgewertet werden müssen.

Ein anderes problem ist das iD automatische änderungen macht wenn das Object geändert wird. Änderungen die nicht im allgemeinen von der Community unterstützt werden.
Dafür kann der benutzer von iD nichts, und es ist keinen direkten grund direkt den gebrauch von iD zu sperren, aber sicher um die Maintainer mal an zu sprechen.

Vielleicht ist es nicht dein Vorsatz, dann aber nimmst du es willentlich in Kauf, was auf’s selbe rauskommt. Denn genau das wird passieren.

Es ist eine Kopie vom Original. Die Änderung sind solche, die die anderen Maintainer erklärtermaßen nicht haben wollen. Und diese neue Version soll auf osm.org installiert werden. Natürlich ist das ein Fork.

Die “Übergangslösung” hält solange, bis sich die Original-Maintainer anpassen oder bis sie das Projekt verlassen. Letzteres wird ganz schnell passieren.

Natürlich betrifft es auch andere Editoren, und das ist auch gut so. Die Regeln müssten sinnvoll und flexibel sein, so dass Entwickler nicht abgeschreckt werden.

Die Gefahr ist natürlich realistisch, wenn man sich z. B. das Debakel um die Organised Editing Guidelines anschaut. Aber dann müssen wir zusehen, den Vorstand geeignet zu besetzen und eine vernünftige Editor-Policy durchzusetzen.

Ich würde es vorziehen, wenn du auf Polemik verzichten könntest. Wenn die Community festlegt, wie etwas zu taggen ist, dann ist das keine „Religion“, sondern Konvention. Auch dass wir Autobahnen highway=motorway nennen und nicht fid7e8=hhdje61, ist Konvention. Beides geht technisch, aufs erste hat man sich geeinigt.

Und Usability gehört nie und nimmer vor Taggingkonvention gesetzt! Weil nur die Konventionen unsere Daten auswertbar machen und halten.

Nochmal: Niemand hat etwas dagegen, dass iD einfach zu bedienen ist. Das kann und soll gern so bleiben.

Es geht hier gegen die Angewohnheit der iD-Entwickler, ohne Diskussion und Konsens Dinge einzuführen, die nicht etabliert sind und nirgends kommuniziert wurden. Das fängt schon mit diesen furchtbaren _1-Tags an (setzt du an ein amenity noch ein amenity, taggt iD das zweite als amenity_1=* – oder hat es jedenfalls mal gemacht, es gibt noch genug Beispiele davon in der Datenbank). Das wurde nie diskutiert und wird nirgends ausgewertet, es wird einfach mal so eingebaut. Das ist keine Art, sich mit einer Software an einem Communityprojekt zu beteiligen, oder?

Und ich behaupte, dass iD auch dann, wenn es sich an etablierte Taggingstandards hält, so einfach bedienbar bleiben kann und nicht zwingend kompliziert wird. Von da her ist „einfach“ und „kompatibel“ kein Widerspruch.

–ks

Das muss alle Editoren betreffen, sonst hat man immer wieder die selbe Diskussion. iD ist ja “nur” die Spitze des Eisbergs.

Letzteren Eindruck kann man bei iD aber auch bekommen, wenn mir beim Selektieren einer Straße gleich die Abbiegebeschränkungen entgegenleuchten, als müssten da unbedingt welche dran :slight_smile:

Du vermischst hier aber zwei Sachen. Ob du die Schranke mit JOSM oder mit iD einträgst, in jedem Fall steht da hinterher ein Node mit barrier=* in der Datenbank. Das kann in beiden Editoren ein schlichtes barrier=gate sein. Dass der OSM-Taggingstandard außerdem noch die Möglichkeit bietet, ein spezielles barrier=lift_gate oder barrier=swing_gate zu setzen, ist nicht die Schuld von JOSM.

iD setzt bei „Schranke“ ein lift_gate, was bei einer Schwenkschranke strenggenommen falsch ist, aber, wie du schon feststellst, kann das dem Anwender einklich egal sein. Dass JOSM es genauer wissen will, ist nicht dessen „Schuld“, sondern wendet nur das OSM-Taggingschema genauer an.

Du bist weder in iD noch in JOSM dazu gezwungen, sämtliche Auswahlfelder zu füllen.

–ks

Nun, ich bitte Dich dies nun nicht in den falschen Hals zu kriegen. Ich habe den Eindruck, dass sehr viele Taggingdiskussionen von der Annahme geprägt sind, dass möglichst alles möglichst detailiert dargestellt werden soll. Da ich noch nie einen vernuenftigen Grund dafuer gefunden habe, habe ich oft den Eindruck dass die Diskussionen darum eine andere Sphäre haben - nu und da habe ich den Vergleich mit einer Religion gezogen. Polemisch war das nicht gemeint.

Und der zweiten Aussage kann ich nicht zustimmen. Ja: Konventionen die so gesetzt werden, dass a) Usability und b) Detailgetreue dabei hierarisch geordnet herauskommen und eben nicht durcheinandergehen, sind absolut sinnvoll und wuenschenswert.

Von mir aus kann man z.B.
barrier=gate
gate_type=swinggate
nehmen, so dass dieser indirekte Zwang zum Detail aufhört.
Genauso kann ich das bei den Strassenbelägen, Dienstleistern und noch vielen, vielen weiteren Punkten sehen.

Klare Konventionen - die auch die Perspektive der Pragmatiker eingeziehen. Eine Checkliste fuer jedes neue Tagging - das immer im die Balance zwischen “Details” und “Benutzbarkeit” im Auge behält. Das sind fuer mich notwendige Kompromisse.

je nachdem welche Quelle man liest merkt man jedenfalls, dass auch die ID Entwickler hier Schwierigkeiten haben. Und aus meiner eigenen Arbeit und den Kontakten mit Anfängern entsteht der Eindruck, dass die Positionen (einer kleinen Gruppe sind einige Dinge sehr wichtig, die breite Mehrheit wuenscht etwas anderes) nur in der Konsequenz (wir ignorieren ganz einfach gewisse Beduerfnisse - diesmal im Streit mit einer kleinen Gruppe) grundsätzlich falsch sind - nicht jedoch die Problembeschreibung.

Und nunja, ausser einigen Facebookgruppen und gelegentlichen Kommentaren im Forum hört man erstaunlich wenig von der Gruppe.

Und wenn ein Organisationsprocess nicht so läuft, dass er in der Lage ist, allen klarzumachen, wie dieser funktioniert, gibt es Probleme - und legitimiert am Ende das Handeln nach dem Moto “ich mach was ich will”.

Wir sollten einfach aufpassen, nicht den Boten zu töten, sondern den Inhalt der Nachricht zu bearbeiten. Sicherlich ist es im Moment nervig, wenn Leute dieses Vorangehen einfach tun - und dann nicht bereit sind, auf einzelne Einwände einzugehen. Ich habe allerdings nach wie vor die Hoffnung, dass die Beteiligten unter Moderation der einzig demokratisch gewählten Instanz die wir haben in der Lage sind, auf eine Metaebene zu gehen und Fragen “wie bewältigen wir den Konflikt zwischen Vereinfachung und Detailtreue”, “wer legt wann wie fest, was die verbindlichen Empfehlungen sind” gemeinsam beantworten.

Ich sehe auch die große Gefahr, dass sich die Entwickler durch öffentliche Vorwürfe, negative Äußerungen über ihre Person und die eventuelle Beschneidung ihrer Kompetenzen persönlich angegriffen fühlen oder das gar als Mobbing auffassen und dass in der Konsequenz die Entwickler und evtl. auch ihre Arbeitgeber das Handtuch werfen.

Der Konflikt ist jetzt schon zu sehr eskaliert, da zusätzlich noch eine Kampagne mit Forderungen und Vorwürfen loszutreten, halte ich für den völlig falschen Weg.

Fragt sich denn niemand, wie es so weit kommen konnte, dass die Entwickler so völlig auf stur schalten? Und ob an der jetzigen Situation nicht auch beide Seiten ihren Anteil haben?

das Ganze (Eingangsposting) hat meine volle Unterstützung !

Doch, das fragen sich bestimmt einige, jedenfalls bist du bestimmt nicht der erste, der auf die Idee kommt :slight_smile:

Nach meiner Erfahrung ist sowas eine schleichende Entwicklung, an der keine Seite tatsächlich schuld hat: Ein Entwickler nimmt sich nach und nach immer mehr Extras raus und man lässt ihn anfangs gewähren, um ihn nicht zu verärgern. Das rächt sich immer, weil irgendwann der Punkt kommt, an dem es weh tut und einer die Notbremse zieht. Der ist IMHO jetzt erreicht. Sonderwege von iD gibt es schon seit Jahren, und sie werden auch schon seit ebensovielen Jahren kritisch betrachtet, aber auch geduldet. Soweit ich das überblicke, war es den Entwicklern von Anfang an nicht besonders wichtig. Gesundes Selbstbewusstsein, um es vorsichtig auszudrücken.

Alle, die sagen, das könne man nicht machen, möchte ich nochmal fragen: Was sollen wir stattdessen machen? Ablehnen ist leicht, Alternativen vorschlagen ist konstruktiv.

–ks

Besonders schwierig macht es die Weigerung des iD Maintainers, sich an irgendeiner Diskussion oder auch einer Mediation zu beteiligen. Ich denke, dass die Ablehnung darauf zurück geht, dass die Art und Weise, wie schwierige Dinge adressiert werden, sich deutlich zwischen USA und DE unterscheiden. Er wird fürchten, einem wütendem, verständnislosen Mob gegenüber zu stehen, der seine gute Arbeit an iD als selbstverständlich hinnimmt und ihn für die problematischen Dinge lynchen will. Statt dessen zieht er sich ins Schneckenhaus US Slack zurück, wo ihm die Leute wohlgesonnen sind und ihn bestätigen - seine Blase sozusagen. Solange er nicht für einen Dialog zur Verfügung steht, bei er sich einer kritischen Diskussion stellt, die auch nicht immer nach seinen gewohnten Spielregeln ablaufen wird, kommt man da nicht weiter - auch nicht wenn man mehr oder weniger freundlich weiter auf ihn einreden würde. Ich hoffe ja, dass die momentane Eskalation bewirkt, dass jemand aus seinem Umfeld ihm sagt, dass das so nicht weiter geht und er sich, ob im Recht oder nicht, bewegen soll. Mein Vorschlag wäre, man sucht sich jemand, der sich mit Bryan versteht und noch zuhört und versucht erstmal herauszufinden, ob es einen Rahmen oder andere Voraussetzungen gibt, in dem Bryan zu einem Dialog bereit wäre. Derjenige müsste ihm auch verklickern, dass andere Leute auch valide Meinungen haben und Kritik nicht immer so äussern, wie er es gerne hätte.

Du suchst aber wieder nur die Schuld beim Entwickler. Es sind vielleicht aber eben auch Ton und Art der Äußerungen aus der Community, die auf die Dauer zermürben können, die auch nicht immer sachlich sind oder zumindest nicht als sachlich und konstruktiv aufgefasst werden.

Aktuelle Äußerung von einem der Enwickler:

https://twitter.com/bhousel/status/1194598491579961344

Übersetzung deepl.com:

(edit: Formatierung inneres quote)

Auch wenn ich nicht alle Links recherchiert habe: Bei den Fällen, die ich mir durchgelesen habe, bin ich immer zu dem Schluß gekommen, daß

  • der Alleingang von ID taggingtechnisch Probleme verursacht und OSM schadet
  • die Kritik berechtigt war und auch sinnvoll in Issues eingereicht wurde
  • der Umgang der Maintainer höchst unprofessionell war (berechtigten input ignorieren, tickets sperren) und haben emotionale Reaktionen erst provoziert

Von daher halte ich diesen Punkt für eine reine Schutzbehauptung, um sich keiner Kritik stellen zu müssen.

Ich glaub auch nicht an Trolle im Kanal, fühle mich eher daran erinnert wie ein Oger namens Shrek verbissen seinen Sumpf gegen jeden Besucher verteidigt… :slight_smile:

Aber gerne. :slight_smile: Ich habe selbst seit fast 2 Jahren einen Fork online (wie oben schon geschrieben) und unterstütze die Forderung nach einem Branch-Wechsel für die Voreinstellungen und Fehlerchecks von ID auf der Hauptseite!

Der erste Schritt wäre anzuerkennen, dass sich beide Seiten gegenseitig Fehlverhalten vorwerfen.

Und dann die Entwickler nach ihrer Sicht fragen und anschließend gemeinsam mögliche Lösungen überlegen und wie man die Kommunikation und den Umgang miteinander verbessern kann. Und da müssten sich dann auch beide Seiten bemühen.

Vielleicht könnte Mikel Maron (“Community team lead at Mapbox”) beim Vermitteln helfen und evtl. ein externer, neutraler Mediator zur Unterstützung geholt werden, wie schon bei den Face-to-Face Meetings des Boards?

Guten Abend.

Ich hab die Disskussion den ganzen Tag schon verfolgt und auch gleich meine Meinung gehabt.

Ich denke doch, daß es höchste Zeit ist, Teile wie z.B. Tagging und deren Vorlagen auf eine breitere Basis zu stellen und mehr Einheitlichkeit zu erreichen. Von daher untersütze ich diese Bestrebungen voll. Letztendlich geht die Disskussion auch schon solange, wie es iD gibt. Bei einigen Dingen ist sicher irgendwann mal was passiert, vielleicht weil der Druck dann doch zu groß wurde…

Aber zu unterstellen, die Community sei von Trollen gekapert, betrachte ich für mich persönlich und für meinen Beitrag für OSM als aller höchste Beleidigung. Dann hat er anscheinend das “Open…” nicht verstanden.

Ich könnte es auch anders schreiben:

“OSM könnte richtig gut funktionieren, wenn es die ganzen Trolle in den Mailinglisten, in den Foren und im Wiki nicht gäbe!” …Nee… So geht das nicht!

Sven

+1
Einen (seltenen) Entwickler zu verlieren ist auch nicht das Gelbe vom Ei.

Ein Vorschlag aus einem Kommentar von Richard (Übersetzung (translate.google.de)):

Übersetzung (deepl.com):