OpenStreetMap Forum

Hartmut Holzgraefe

Member

Registered: 2015-04-13

Posts: 263

Re: Spielplatz mit access=yes?

OSM_RogerWilco wrote:

    Natürlich. Wenn die Benutzung lediglich geduldet wird, ist das access=permissive.

Klar, in der Theorie auf jeden Fall, ist mir in der Praxis bei Spielplätzen aber noch nie begegnet.

Ich muss dafür nur ca. 200m laufen: Spielplatz auf dem Schulhof einer Grundschule der nachmittags auch für Kinder freigegeben ist, die nicht zu dieser Schule gehen, und ein bestimmtes Höchstalter nicht überschreiten.

Oder währe das eher ein Fall für access:conditional mit max. age und opening hours?

OSM_RogerWilco

Member

From: Heidekreis (Niedersachsen)

Registered: 2019-08-27

Posts: 1,235

Re: Spielplatz mit access=yes?

Oder währe das eher ein Fall für access:conditional mit max. age und opening hours?

Ich habe das bisher ohne access und dafür mit opening_hours gelöst.

Luzandro

Member

Registered: 2015-12-16

Posts: 599

Re: Spielplatz mit access=yes?

Und wenn ein Spielplatz aus welchen Gründen auch immer längerfristig/auf unbestimmte Zeit gesperrt ist? Kontamination festgestellt oder Senkungsgebiet und die tatsächliche Gefährdung muss erst untersucht werden, etc... Und was otg vorhanden ist, kann und soll gemappt werden.

Das ist aber eher ein Fall für disused

eginhard

Member

From: Switzerland

Registered: 2021-03-25

Posts: 12

Website

Re: Spielplatz mit access=yes?

Oder es hat einfach noch niemand eingetragen. Oder jemand hat es ohne Nachfrage gelöscht. Oder...

Youah ... das gilt dann aber für alle Informationen im Wiki - entweder haben die richtungsgebenden Character oder eben nicht, weil jeder drin rumbasteln kann.

Die Infos im Wiki sollten eher deskriptiv, als preskriptiv sein (https://wiki.openstreetmap.org/wiki/Wik … nformation).

Eine kurze Beschreibung zur Benutzung von access=yes bei Spielplätzen habe ich mal hinzugefügt: https://wiki.openstreetmap.org/w/index. … id=2208120

skyper

Member

Registered: 2020-06-08

Posts: 687

Re: Spielplatz mit access=yes?

Bitte schau über den Tellerrand. Jeder Editor hinterlässt seinen Fußabdruck, die Frage ist nur wie groß der ist. Als Person, die einige Software gar nicht benutzt, werde ich trotzdem öfters mit deren Taggingschema und auch mit noch nicht akzeptierten und kontroversen Tags konfrontiert. Das ist schon ein Aufdrücken, oder?

Wenn man das weiterdenkt, ist ganz OSM ein Aufdrücken, oder?

Ohne Vetorecht auf jeden Fall.

Als einzelne Person, ist meine Reichweite natürlich begrenzt und es muss in vielen kleinen CS getarnt werden, aber als organisiertes Team geht das schon viel besser. Wenn jetzt Editor-Software das auch noch anmahnt und/oder mehr oder weniger im Hintergrund macht, ist es bedenklich.

Wir habe ja schon eine Spielregeln und Mechanismen, um uns auf Tags und Taggingschemata zu einigen. Diese sollten wohl ein bisschen verfeinert werden, wie z.B. die Abstimmung zu Internetbezahlsystemen gezeigt hat. Auch die Definitionen des Tagstatus halte ich für zu schwammig. Ab wann ist ein Tag "proposed", "in use" oder "de facto"?
Auf Seite der Personen, die an der Entwicklung von Editoren beteiligt sind, erwarte ich mehr Fingerspitzengefühl und die Verwendung von etablierten Tags oder ein entsprechendes akzeptiertes Proposal. Hier fehlt es eventuell auch ein paar generellen Richtlinien als Leitfaden.

Zwei Beispiele noch zu Verdeutlichung:
* `railway=tram_crossing` und `railway=tram_level_crossing`, hier bestehen nach wie vor Überlappungen mit `railway=crossing` und `railway=level_crossing` und der neue Tag verändert die Definition des existierenden. Es gibt kein Proposal.
* `cycleway:both=*` ohne `oneway=*`, wird massenweise getaggt, dabei kann das "both" weggelassen werden. Hier wird die Definition von `cycleway=*` verwässert.

Wenn sich niemand findet, um diese Definitionsthemen voranzutreiben, wird es leider so aufdrückend bleiben. Nun finde ich immer noch, dass nicht die Entwickler der Editoren hier etwas aufdrücken. Diese nicht vollständig definierten Tags drücken hier wohl eher auf. Man kann Tags wohl auch nie 100% vollständig definieren, sodass es immer Verwässerungen und Ausnahmen der Ausnahme gibt.
Das Problem bliebe selbst bestehen, wenn ich direkt in die Datenbank per Hand schreibe ohne Editor und mit ganz viel Fingerspitzengefühl. ¯\_(ツ)_/¯

Denkst du, dass die Entwickler von SC nicht genug Fingerspitzengefühl haben? Das Problem ist doch die schwammige Definition und das nicht-Vorhandensein von Standardwerten, die einige Mapper annehmen, die aber nirgends dokumentiert sind.

Ich nehme mal an, ein großer Teil der `access=yes` wurden ohne einen Blick ins Wiki gesetzt.
Es ist doch ein großer Unterschied, ob ich was per Hand eintrage oder ob mich die Software dazu einlädt und ja auch bei SC erwarte ich mehr Kommunikation im Voraus.

Wenn es unklare Definitionen gibt, sollten wir die verbessern oder verfeinern. Dafür haben wir die Diskussionskanäle und am Ende das Proposal. Einfach bisher kaum genutzte Tags, die auch noch andere Tagdefinitionen beeinflussen bis verändern, als offiziellen Tags zu promoten ist Murks.

Um zu versuchen, den Bogen zum Thema zu finden: Wie tagge ich einen Spielplatz als öffentlich, wenn nicht mit access=yes? Oder sollten deine zwei Beispiele hier besser herhalten - nur wie?

Die beiden Beispiele sind eindeutiger und ich kann sie belegen, aber das Thema ist zumindest bei `cycleway=both` das gleiche. `tram_crossing` ist eher iD, aber ein sehr gutes Beispiel.
Wie sich oben ja schon rausgestellt hat bringt das `access=yes` SC eigentlich kein Stück weiter, sondern verhindert viel eher, dass eine Abfrage häufiger gestellt wird. Dann Frage ich mich jetzt wozu das ganze?

skyper

Member

Registered: 2020-06-08

Posts: 687

Re: Spielplatz mit access=yes?

Das Wiki ist ja kein Regelbuch für OSM, sondern dient uns lediglich als Notizbuch unsere Diskussionsergebnisse zu dokumentieren.   So sollte man das Wiki jedenfalls betrachten.

+1, leider fehlen hier aber auch häufig Links zu den Diskussion oder eine kurze Zusammenfassung des Ergebnis.

Oder es hat einfach noch niemand eingetragen. Oder jemand hat es ohne Nachfrage gelöscht. Oder...

Youah ... das gilt dann aber für alle Informationen im Wiki - entweder haben die richtungsgebenden Character oder eben nicht, weil jeder drin rumbasteln kann.

Es ist eine von mehreren Quellen und eher Richtlinien als Gesetzte. Wie jedes andere Wiki, sollten die Diskussion, welche eventuell auch nur auf anderen Seiten oder Mailinglisten geführt wurden, gelesen werden. Die zitierten Quellen selbst anzuschauen ist auch nicht schlecht.

Ich habe erst neulich die Vorlagen von Kraftwerken und von Pumpen in JOSM überarbeitet. Das ging super, da es angenommen Proposals gab und klare Wiki-Seiten. Zusätzlich habe wir auch direkten Kontakt mit der Person, welche die Proposal eingebracht hat.
Wenn ich mir da andere Seiten, wie z.B. die Barriere-Tags, anschaue, ist es wesentlich schwieriger. Da musste ich erst einigen Aufwand betreiben, um die Informationen, wie Status, zu überprüfen und Diskussionen zu finden.
Der eigentliche Koden ist nicht so kompliziert bis auf das Icon, die meiste Zeit braucht es aber meist, sich einen Überblick über den Tag zu machen.

Last edited by skyper (2021-11-10 15:26:43)

Strubbl

Member

Registered: 2020-08-27

Posts: 150

Re: Spielplatz mit access=yes?

Ich nehme mal an, ein großer Teil der `access=yes` wurden ohne einen Blick ins Wiki gesetzt.

Natürlich. Das ist doch die Stärke dieser SC App. D.h. ja nicht, dass die Quest ohne Blick ins Wiki erstellt wurde. Hmm, schaust du bei jedem Setzen eines Access Tags an ein Objekt ins Wiki?

Es ist doch ein großer Unterschied, ob ich was per Hand eintrage oder ob mich die Software dazu einlädt und ja auch bei SC erwarte ich mehr Kommunikation im Voraus.

Kommunikation im Voraus würde was genau bedeuten? Meinst du der App-Nutzer soll erfahren, was seine Antwort für Auswirkungen auf die DB hat außer das der Spielplatz nun als öffentlich geführt wird? Wie genau sollte das gehen? Dass der Nutzer erstmal eine Textwand bekommt, die er lesen und dann akzeptieren drücken muss? Was nie einer tun würde. Ich wüsste nicht wie so etwas sinnvoll umgesetzt werden soll. JOSM nimmt auch nicht gerade an die Hand und sagt mir, was passiert, wenn ich "Ausgewiesener Radweg" auswähle. Analog dazu iD. Die Tags sind dann anschließend einfach da. Ich kann sie noch bestaunen, aber wenn ich keine Ahnung von den Tags habe, nützt es mir nichts.
Deswegen wäre es cool, hier einen wirklichen Verbesserungsvorschlag zu bekommen.

Wie sich oben ja schon rausgestellt hat bringt das `access=yes` SC eigentlich kein Stück weiter, sondern verhindert viel eher, dass eine Abfrage häufiger gestellt wird. Dann Frage ich mich jetzt wozu das ganze?

Im Falle das die Objekte eben ewig nicht geändert werden, ist es doch nicht so. Nur in dem von dir konstruierten Sonderfall mit dem Teilen eines Fuß-/Radweges. Das ist wie gesagt nur ein Sonderfall und nicht der Normalfall. Wie oft wird ein Spielplatz geändert nachdem access=yes hinzukommt? Ich denke auch, dass das ein Sonderfall ist. Weiterhin würde es doch nichts bringen, die Abfrage häufig zu stellen im Vergleich dazu wie sich diese Begebenheit (access yes) ändert.

Last edited by Strubbl (2021-11-10 18:25:21)

MKnight

Member

Registered: 2012-08-01

Posts: 2,406

Re: Spielplatz mit access=yes?

Es ist doch ein großer Unterschied, ob ich was per Hand eintrage oder ob mich die Software dazu einlädt und ja auch bei SC erwarte ich mehr Kommunikation im Voraus.

Kommunikation im Voraus würde was genau bedeuten? Meinst du der App-Nutzer soll erfahren, was seine Antwort für Auswirkungen auf die DB hat außer das der Spielplatz nun als öffentlich geführt wird?

Also _mir_ ging es drum, dass Editoren wie bspw. iD und oder SC oder sonstwas vorher fragen und dokumentieren müssen, ob Tagging-XY ok ist für die Community (oder nicht!) und nicht irgendwas erfinden, das der "App-Nutzer(!)" anhaken kann oder nicht. Ich glaub Du hast da sowohl bei skyper als auch bei mir was komplett falsch verstanden. (vorausgesetzt, ich verstehe skyper richtig )
Man kann eben NICHT erwarten, dass $User vorher ins Wiki schaut, ob TaggingXY etabliert ist. Das ist nicht schön, aber völlig ok.
Wenn mir aber als Noob eine Software unter die Arme greift, dann gehe ich (als Noob) davon aus, dass das schon seine Richtigkeit hat und/oder dass das Usus und wichtig ist hier oder dort einen Haken zu setzen.

P.s. Die Talsohle von solchen Schnellschüssen war meiner Meinung nach erreicht, als iD name_1, amenity_1 und dergleichen Blödsinn in die DB gekackt hat.

---

gesammelte Overpass-abfragen zu QA (hauptsächlich Strassenfehler) + verschiedene Stats zu Strassen-eigenschaften

Map_HeRo

Member

From: Hessisch Sibirien

Registered: 2021-11-01

Posts: 737

Re: Spielplatz mit access=yes?

Also _mir_ ging es drum, dass Editoren wie bspw. iD und oder SC oder sonstwas vorher fragen und dokumentieren müssen, ob Tagging-XY ok ist für die Community (oder nicht!) und nicht irgendwas erfinden, das der "App-Nutzer(!)" anhaken kann oder nicht. Ich glaub Du hast da sowohl bei skyper als auch bei mir was komplett falsch verstanden. (vorausgesetzt, ich verstehe skyper richtig )
Man kann eben NICHT erwarten, dass $User vorher ins Wiki schaut, ob TaggingXY etabliert ist. Das ist nicht schön, aber völlig ok.
Wenn mir aber als Noob eine Software unter die Arme greift, dann gehe ich (als Noob) davon aus, dass das schon seine Richtigkeit hat und/oder dass das Usus und wichtig ist hier oder dort einen Haken zu setzen.

Youah, genau das ist auch mein Anliegen gewesen. Dass die User theoretisch jeden Unsinn taggen können, den man sich vorstellen kann (man braucht ja nur mal einen Blick in die TagInfo eines beliebigen Keys werfen ...) ist eine Sache und auf Grund der OSM Struktur vermutlich kaum zu vermeiden, aber dass ein Editor den unerfahrenen User im Prinzip dazu auffordert, unerwünschte oder zumindest strittige Attribute zu setzen, könnte m.E. durch eine entsprechende Abstimmung vor dem Release vermieden werden.

Strubbl

Member

Registered: 2020-08-27

Posts: 150

Re: Spielplatz mit access=yes?

Das ist ja schön und gut. Und jeder möchte gerne gefragt werden bevor etwas in die DB kommt. Aber wie stellt man sich das in der Praxis vor? Das ist mir nicht konrekt genug, als dass man mit diesen Infos irgendeine App/Editor verbessern könnte.

R0bst3r

Member

Registered: 2015-04-23

Posts: 686

Re: Spielplatz mit access=yes?

Das Wiki ist ja kein Regelbuch für OSM, sondern dient uns lediglich als Notizbuch unsere Diskussionsergebnisse zu dokumentieren.   So sollte man das Wiki jedenfalls betrachten.

+1

---

OSM Profis sollten Anfänger mehr ermuntern und mehr unterstützen, damit die Gemeinschaft wächst und vielfältiger wird. Momentan vergrault man immer noch gerne.

Map_HeRo

Member

From: Hessisch Sibirien

Registered: 2021-11-01

Posts: 737

Re: Spielplatz mit access=yes?

Das Wiki ist ja kein Regelbuch für OSM, sondern dient uns lediglich als Notizbuch unsere Diskussionsergebnisse zu dokumentieren.   So sollte man das Wiki jedenfalls betrachten.

+1

Dann sollte aber für die Neumapper, die dort Rat und Regeln suchen, oben auf jeder Seite stehen "Bitte nicht dran halten ... das sind keine Mappingregeln, sondern nur Diskussionsnotizen."

Map_HeRo

Member

From: Hessisch Sibirien

Registered: 2021-11-01

Posts: 737

Re: Spielplatz mit access=yes?

Das ist ja schön und gut. Und jeder möchte gerne gefragt werden bevor etwas in die DB kommt. Aber wie stellt man sich das in der Praxis vor? Das ist mir nicht konrekt genug, als dass man mit diesen Infos irgendeine App/Editor verbessern könnte.

Leider blicke ich noch nicht wirklich durch, wie das ganze OSM Gebäude strukturiert ist oder auch nicht. Daher kann ich keine konkreten Vorschläge machen, wie diese Handling in der Praxis verbessert werden könnte. Aber Kommunikationsplattformen gibt es ja genug. Es gibt daher sicher Möglichkeiten für die Entwickler, neue Editoren oder neue Releases der Community vorzustellen, falls das nicht ohnehin in irgendeiner Form geschieht.

skyper

Member

Registered: 2020-06-08

Posts: 687

Re: Spielplatz mit access=yes?

Ich nehme mal an, ein großer Teil der `access=yes` wurden ohne einen Blick ins Wiki gesetzt.

Natürlich. Das ist doch die Stärke dieser SC App. D.h. ja nicht, dass die Quest ohne Blick ins Wiki erstellt wurde. Hmm, schaust du bei jedem Setzen eines Access Tags an ein Objekt ins Wiki?

Ich bin da wohl nicht das beste Beispiel, denn ja, ich lese viel im Wiki und habe u.a. etliche "access"-Wikiseiten auf meiner Beobachtungsliste.

Es ist doch ein großer Unterschied, ob ich was per Hand eintrage oder ob mich die Software dazu einlädt und ja auch bei SC erwarte ich mehr Kommunikation im Voraus.

Kommunikation im Voraus würde was genau bedeuten? Meinst du der App-Nutzer soll erfahren, was seine Antwort für Auswirkungen auf die DB hat außer das der Spielplatz nun als öffentlich geführt wird?

Also _mir_ ging es drum, dass Editoren wie bspw. iD und oder SC oder sonstwas vorher fragen und dokumentieren müssen, ob Tagging-XY ok ist für die Community (oder nicht!) und nicht irgendwas erfinden, das der "App-Nutzer(!)" anhaken kann oder nicht. Ich glaub Du hast da sowohl bei skyper als auch bei mir was komplett falsch verstanden. (vorausgesetzt, ich verstehe skyper richtig )
Man kann eben NICHT erwarten, dass $User vorher ins Wiki schaut, ob TaggingXY etabliert ist. Das ist nicht schön, aber völlig ok.
Wenn mir aber als Noob eine Software unter die Arme greift, dann gehe ich (als Noob) davon aus, dass das schon seine Richtigkeit hat und/oder dass das Usus und wichtig ist hier oder dort einen Haken zu setzen.

P.s. Die Talsohle von solchen Schnellschüssen war meiner Meinung nach erreicht, als iD name_1, amenity_1 und dergleichen Blödsinn in die DB gekackt hat.

+1

Sprache und das Verstehen kann ja richtig kompliziert sein, aber immerhin eine Person hat mich wohl verstanden.

Wie sich oben ja schon rausgestellt hat bringt das `access=yes` SC eigentlich kein Stück weiter, sondern verhindert viel eher, dass eine Abfrage häufiger gestellt wird. Dann Frage ich mich jetzt wozu das ganze?

Im Falle das die Objekte eben ewig nicht geändert werden, ist es doch nicht so. Nur in dem von dir konstruierten Sonderfall mit dem Teilen eines Fuß-/Radweges. Das ist wie gesagt nur ein Sonderfall und nicht der Normalfall. Wie oft wird ein Spielplatz geändert nachdem access=yes hinzukommt? Ich denke auch, dass das ein Sonderfall ist. Weiterhin würde es doch nichts bringen, die Abfrage häufig zu stellen im Vergleich dazu wie sich diese Begebenheit (access yes) ändert.

Als Konstrukt wurde ich den Fall des Ändern des Objekttypen halten, aber darüber haben wir noch gar nicht geredet. Das Teilen von Wegen als Sonderfall dazustellen ist in meinen Augen eine Verharmlosung.
Ich habe doch schon allein beim Verschieben des Knoten oder beim Einfügen eines Knoten in eine Linie eine neue Version. Daran hakt es doch schon. Default Werte bringen uns nicht wirklich weiter, sondern es braucht ein besseres System von SC oder OSM den Verlauf abzubilden. Ob SC sich jetzt speichert, wann welche Frage das letzte mal gestellt wurde oder eine schöne Semantik für "deep history" verwendet, ist mir erst einmal gleich. Meinen Vorschlag, lieber alle Tags regelmäßiger überprüfen zu lassen (und dies zu Speichern), anstatt immer nur einen, war durchaus ernst gemeint. Ich wundere mich halt auch immer über das massenweise `cycleway:both=no` in Wohngebieten aber von `sidewalk=*` fehlt jede Spur, obwohl real vorhanden.
So wie das Konzept im Moment ist, ist es mMn. zu kurz gedacht.

OSM_RogerWilco

Member

From: Heidekreis (Niedersachsen)

Registered: 2019-08-27

Posts: 1,235

Re: Spielplatz mit access=yes?

Dann sollte aber für die Neumapper, die dort Rat und Regeln suchen, oben auf jeder Seite stehen "Bitte nicht dran halten ... das sind keine Mappingregeln, sondern nur Diskussionsnotizen."

Das hast Du jetzt falsch wiedergegeben bzw. falsch verstanden. Wir dokumentieren dort vor allem unsere Diskussionsergebnise. Nicht selten wird auch einfach nur das aktuelle Taggingverhalten dokumentiert. So nach dem Motto: "Die meisten Mitwirkenden mappen ein XYZ so und so." Es liegt in der Natur von OSM, dass man sich daran orientieren kann aber nicht muss. Kann also bedeuten, dass in 10 Jahren dort etwas anderes steht, weil sich das Verhalten verändert hat und ein anderes Tagging-Schema sich zwischenzeitlich durchgesetzt hat. Was ich außerdem mit dem Satz sagen wollte: Wir entscheiden gemeinsam, was dort steht. Wenn dort etwas noch nicht steht, heißt das nicht, dass das dann nicht trotzdem sinnvoll und richtig ist.

Für Anfänger:innen ist das tatsächlich schwer, ja das stimmt. Das ging mir auch so und ich wünschte mir nicht selten, dass irgendwo ganz eindeutig geschrieben steht, wie was zu Mappen ist. Ein festes Regelwerk. Gibt es aber nicht. Muss man mit leben.

Map_HeRo

Member

From: Hessisch Sibirien

Registered: 2021-11-01

Posts: 737

Re: Spielplatz mit access=yes?

Das hast Du jetzt falsch wiedergegeben bzw. falsch verstanden.

Chef, ick hab dat schon voll richtig und jut verstanden, wie man auch am Zwinkersmiley, der am Ende meiner flapsigen Bermerkung steht (und in dem Zitat fehlt), erkennen hätte können sollen ...:).

Für Anfänger:innen ist das tatsächlich schwer, ja das stimmt. Das ging mir auch so und ich wünschte mir nicht selten, dass irgendwo ganz eindeutig geschrieben steht, wie was zu Mappen ist. Ein festes Regelwerk. Gibt es aber nicht. Muss man mit leben.

Ich betrachte das Wiki schon als Regelwerk, da es stets den aktuellen Mindest-Konsens der Beteiligten abbildet und andere Regeln nicht zur Verfügung stehen. Dass dieses "Regelwerk" lebt und ständig aktualisiert wird, spricht ja nicht dagegen. Was man sicher deutlich verbessern könnte, sind klare Hinweise für Neumapper, wie diese "Regeln" anzuwenden sind, was besonders wichtig ist und was man eher vernachlässigen kann und so weiter. Wenn man mit der komplexen OSM-Architektur noch nicht wirklich vertraut ist, kann man sich bei dem einen oder anderen Thema in den Tiefen der Wikis dumm und dusslig suchen, und dann sind die Hinweise zum Teil auch noch widersprüchlich und nicht immer logisch nachvollziehbar.

Ein anderer Neumapper schrieb dazu:

"Und so geht es mir bei vielen Dingen hier: Ich weiß zwar die Theorie dahinter, aber ich habe keine Erfahrung mit der praktischen Umsetzung. Ich will alles richtig machen, also lese ich sorgfältig nach, aber weil OSM nun mal organisch gewachsen ist, finde ich im Wiki (und sonst wo) widersprüchliche Angaben. Dann habe ich Angst, entweder was falsch zu machen oder gar zwischen die Fronten irgend eines Streits zu geraten, und mache im Zweifelsfall gar nichts."

Wenn ich ein bisschen mehr praktische Erfahrung gesammelt habe, werde ich mich mit diesem Thema mal intensiver beschäftigen und ein paar Vorschläge dazu machen ... ich komme ja aus diesem Arbeitsfeld (Lastenhefterestellung und Anwenderdokumentation für DB-Anwendungen) und bringe zumindest für die Dokumentationsseite eine gewisse Expertise mit. An der fachlichen Seite arbeite ich noch ...:)

SafetyIng

Member

Registered: 2021-01-22

Posts: 464

Re: Spielplatz mit access=yes?

ch betrachte das Wiki schon als Regelwerk, da es stets den aktuellen Mindest-Konsens der Beteiligten abbildet und andere Regeln nicht zur Verfügung stehen. Dass dieses "Regelwerk" lebt und ständig aktualisiert wird, spricht ja nicht dagegen.

Schließe ich mich vollständig an. Wofür macht man denn sonst eine Dokumentation?
Dieses Regelwerk würde ich persönlich einfach noch mal in zwei Ebenen der "Verbindlichkeit" unterteilen. 1. Das was durch ein Proposal lief dann ist es u.a. für die Editoren mMn als Verpflichtend anzusehen. Und wenn ein Editor eine Sache einführen will, dann muss dementsprechend ein Proposal gemacht werden.
2. Das was "in use"/"de facto" ist, ist halt eine Grauzone; Dokumentiert / ggf Manifestiert in der Nutzung und somit eine Richtschnur.