DE:Proposal process

From OpenStreetMap Wiki
(Redirected from DE:Proposed features)
Jump to navigation Jump to search
Proposal process - Other languages

Diese Seite beschreibt den Proposal-Prozess (zu deutsch: Vorschlagprozess), der eines von mehreren Verfahren zur Einführung neuer Tags ist. Die anderen Wege sind i.d.R. nicht dokumentiert. Diese Seite dient als Hilfestellung für alle, die einen Vorschlag unterbreiten wollen. Durch das strikte Befolgen der Schritte kann der Prozess beschleunigt werden. Die folgende Beschreibung ist jedoch als Hilfestellung, nicht als Verordnung, zu verstehen.

Der Proposal-Prozess wurde entworfen, um mit der Gemeinschaft über einen Standard zum Tagging bestimmter Objekte diskutieren und abstimmen zu lassen. OSM hat prinzipiell keine inhaltlichen Beschränkungen und alle Tags können an Knoten, Wege und Relationen angebracht werden. Es steht dir prinzipiell frei, beliebige Tags zu benutzen. Trotzdem ist es von Vorteil, sich auf eine empfohlene Liste an Tags zu einigen.

Zur Beachtung: Der Ausgang einer Abstimmung über ein Proposal (incl. Bestätigung oder Verwerfen von Tags) hat keinen Einfluss auf die Programme, die die Daten generieren und verarbeiten. Zu nennen sind hier der Standard-Tile-Layer oder die Vorlagen der Editoren. Es sollte nicht erwartet werden, dass ein verabschiedetes Proposal selbstverständlich zu einer Änderung der Kartendarstellung oder von Vorlagen führt. Dies wird von den zuständigen Personen umgesetzt (oder auch nicht). Das Ergebnis eines Proposals sollte nie Anlass großflächiger Änderungen bestehender Daten sein.

Proposals werden für gewöhnlich auf Englisch erstellt. Auf deren Grundlage wird abgestimmt, zusätzliche Übersetzungen sind selbstverständlich möglich.

Liste der Proposals

Alle Proposals werden nach ihrem Status kategorisiert, welcher in der Vorlage Proposal page festgelegt wird:

Bevor ein Proposal gestartet wird

Bestehende tags/proposals

Bevor du ein Proposal startest, gehe folgende Checkliste durch:

Wurde eine Idee bereits abgelehnt, heißt das nicht, dass man sie nicht erneut vorschlagen kann. Manche Vorschläge fallen durch, weil sie nicht ausreichend ausgearbeitet waren: schwammige, nicht eindeutige Definitionen oder mangelhafte Informationen zur Bewertung der Signifikanz. Der Wert mancher Ideen wird erst im Laufe der Zeit deutlich und damit auch die Bedeutung für eine Karte.
  • Gibt es noch eine Arbeit die auf diesen Spezialseiten nicht verzeichnet ist? Prüfe das mit einer allgemeinen Suche im Wiki, benutze dazu die passenden Stichwörter.
Beispiele:
  • Du suchst ein Tag für eine Rennstrecke (racecourse); berücksichtige bei der Suche "racing", "horse", etc.
  • Du suchst ein Tag für Halbinsel (peninsula); berücksichtige bei der Suche auch "headland", "point", etc.
  • Du suchst ein Tag für Brauerei (brewery); berücksichtige bei der Suche auch "beer", "manufacturing", "alcohol", "industrial", "plant", "works", etc.
  • Und es lohnt sich in jedem Fall auch vorab schon einmal die Idee in der Tagging-Mailingliste (auf Englisch) vorzustellen, bevor man das Proposal ausformuliert.

Signifikanz

Ist das Tag, das du vorschlagen möchtest, wert es einzuführen? Prüfe den möglichen Nutzen für die Karte und insbesondere die Daten, die du damit hinzufügen möchtest. Diese Bewertung ist sehr schwierig. Wenn du die Daten hinzufügen möchtest, ist das im allgemeinen Grund genug, ein Tag dafür zu erfinden. Folgende Fragen möchten bei der Bewertung helfen:

  • Ist es ein Reiseziel / Ausflugsziel etc. ?
    • Leute suchen Orte wie z.B. Nationalparks, Bus-Haltestellen, Adressen oder einen Müllabladeplatz
  • Wie viele Ziele dieser Art sind Deiner Meinung nach auf der Welt zu finden?
    • Nehmen wir an, du willst eine Flugzeug-Triebwerkfabrik eintragen - Es gibt davon nur sehr wenige in der Welt, dass es kaum lohnt, dafür ein spezielles Tag zu erfinden. Die Einträge sind besser aufgehoben, wenn man das bereits existierende Tag man_made= nutzt und dann spezifiziert mit product=aero_engines.
  • Wie groß ist das Ziel?
    • Große Ziele können die Navigation unterstützten
  • Ist es für Forschungsarbeiten/Studien nützlich?
    • Ein Geografiestudent möchte vielleicht in einer bestimmten Region die Gesamtfläche aller Nationalparks erfassen.
    • Ein Soziologiestudent möchte in einem Gebiet vielleicht die Korrelation zwischen Anzahl und Position von Porsche-Geschäften und Häusern größer als 600 m2 ermitteln.
    • Ein Geschichtsstudent möchte vielleicht darstellen, wo überall in einem bestimmten Krieg Schlachten stattfanden.
  • Hilft es bei einer Routen-Planung?
    • Es ist nützlich zu wissen, welche Kreuzungen mit Ampelanlagen und welche mit Kreisverkehren ausgestattet sind, weil sich dies auf die Reisezeit auswirkt.
    • Lkw-Fahrer müssen wissen, welches die maximale Durchfahrtshöhe unter Brücken ist oder wie groß das maximale Gewicht ist, mit dem sie Ortschaften durchqueren dürfen.
    • Einrichtungen zur Verkehrsberuhigung wirken sich ebenfalls auf die Reisezeit aus. Verkehrsberuhigte Zonen werden von Routing-Software umgangen.
    • Wanderer interessieren sich für die Oberfläche/Befestigung der Wanderwege.

Vereinbarkeit mit bestehenden Konventionen

In OpenStreetMap gibt es einige Prinzipien. Proposals sollten ihnen folgen oder zumindest erklären, warum sie es nicht tun. Bitte lese sie vorher durch.

Besonders relevant können folgende Prinzipien sein:

Überprüfbarkeit
Akzeptierte Attribute beschreiben meist Objekte oder Eigenschaften, deren Richtigkeit eine Person individuell bestätigen oder widerlegen kann. Ein überprüfbares Tag beschreibt solche Eigenschaften, wobei verschiedene Mapper unabhängig voneinander das gleiche Attribut vergeben würden.
Dadurch sind statistische (z. B. Anzahl Kfz pro Stunde auf einer Straße) und subjektive Eigenschaften (z. B. Bewertungen, Vergleiche) von OpenStreetMap ausgeschlossen. Temporäre, historische oder spekulative zukünftige Inhalte zählen auch dazu.
Ein Objekt, ein OSM-Element
Ein einzelnes Objekt der realen Welt sollte mit einem Element(en) repräsentiert werden.
Syntax-Konventionen für neue Attribute
Es gibt einige Namenskonventionen für Schlüssel und Werte. Wenn du ihnen folgst, können andere Mapper die Bedeutung erahnen, ohne die Erklärung lesen zu müssen. Die Benutzung von Semikola(en) sollte besonders gründlich bedacht werden.

Ein Überfliegen der Bearbeitungsstandards und -konventionen könnte ebenfalls hilfreich sein. Dinge sollten so kartiert werden, wie sie in der Realität sind, fixme=* sollte für Abschätzungen verwendet werden und die besondere Bedeutung von Namen (Unterschied zwischen Namen und Beschreibungen, keine Abkürzungen) sollte bedacht werden, falls das für deinen Vorschlag relevant sein könnte.

Erstellung einer Proposal Seite

Man erstellt eine Seite in diesem Wiki (Namensschema: Proposal:Proposal name, Hilfe von MediaWiki zur Seitenerstellung) und beschreibt diese Seite, indem man den unten stehende Vorlage ausfüllt. Zusätzlich setzt man den Status auf Draft und draftStartDate=2024-11-21 auf das aktuelle Datum mit dem Format JJJJ-MM-TT.

Entwurf eines Proposals

Man kopiere die folgende Textvorlage auf eine neu erstellte Wiki-Seite und fülle die Lücken aus. 

{{Proposal page
|name           = 
|user           = 
|key            = 
|value          = 
|type           = 
|definition     = 
|appearance     = 
|status         = 
|draftStartDate = 
|rfcStartDate   = 
|voteStartDate  = 
|voteEndDate    = 
}}

== Proposal ==
== Rationale ==
== Examples ==
== Tagging ==
== Applies to ==
== Rendering ==
== Features/Pages affected ==
== External discussions ==
== Comments ==
Please comment on the [[{{TALKPAGENAME}}|discussion page]].

Dadurch wird die Vorlage {{Proposal page}} eingebunden, die die Details des Proposals in einer Box zusammenfasst. Mit der Funktion Vorschau zeigen kann man die Ausgabe überprüfen. Nach den beiden geschweiften Klammern beginnt der Hauptteil des Proposals.

Details der Seite

Grundsätzlich: sei ausführlich. Je mehr Informationen du beisteuern kannst, um so besser. Fotos, Beschreibungen, Situationen, Beispiele. Alles was zu einer differenzierten Sicht beiträgt.

Diese Liste beinhaltet Vorschläge, welche Beiträge du in dein Proposal einfügen könntest.

Vorschlag (Proposal)
Eine kurze Beschreibung, was du kartieren möchtest, einschließlich Links zu relevantem Material, wenn möglich mit Fotos.
Begründung
Warum der Tag notwendig ist, mit Berücksichtigung der Signifikanz und dem möglichen Nutzen der Daten.
Beispiele
Namen, Orte, grobe Einschätzung der zu erwartenden Anzahl (z.B. an jeder Straßenecke, ein paar in jedem Ortsteil von Deutschland, ein halbes Dutzend in jedem Land von Süd-Amerika).
Tagging
Die Kategorie des Tags fällt unter (man_made, waterway, tourism, etc.), mit einer Begründung, warum andere ähnliche Kategorien nicht passen (Beispiel: Zur Erfassung der Gebäudenutzung könnte man die Nutzung für jedes Gebäude einzeln angeben. Gegenwärtig wird jedoch die Eigenschaft residential=* an den Flächen, die mit landuse=residential bezeichnet sind, benutzt, da individuelle Angaben für jedes Gebäude zu aufwändig wären.)
Der Name des Tags - Halte ihn so kurz wie möglich (15 Buchstaben sollten möglichst das Maximum sein). Dabei muss er logisch sein und ausreichend beschreibend, damit er kaum Erklärungen benötigt. Des Weiteren darf er nicht bereits als Tag einer anderen Kategorie existieren. Bezeichnungen in britischem Englisch werden vorgezogen.
Andere signifikante Tags zur Beschreibung spezieller Eigenschaften des Eintrags (z.B. Autor eines Kunstwerks, Inhalt einer Pipeline etc.)
Allgemeine Tags, die in vielerlei Zusammenhängen verwendet werden können (z.B., name, operator, access, etc.).
Anwendung als
nodes (Knoten), ways (Linie) oder areas (Fläche); Bei der Abwägung Knoten versus Fläche gilt allgemein, wenn ein Objekt kleiner ist als 5 m mal 5 m, wird es nicht als Fläche, sondern als Knoten kartiert.
Rendering
Ein Proposal wirkt sich nicht automatisch auf das Rendering einer Karte aus. Um das Rendering eines Vorschlags anzustoßen, ist meistens ein Hinweis notwendig, mit dem der Renderer auf das neue Objekt aufmerksam gemacht wird. Am besten liefert man auch direkt die Beschreibung eines Icons oder besser noch ein Beispiel-Icon mit (siehe Map Icons).
Betroffene Map-Features und Seiten
Dieser Abschnitt nennt die betroffenen Schlüssel und Tags sowie die betroffenen Wiki-Seiten.
externe Diskussionen
Hier sollen Verweise auf externe Diskussionen angebracht werden (Mailinglisten, Foren, ...).
Kommentare
Es sollte eine gewisse Zeit für Kommentare eingeräumt werden, in der andere Mapper ihre Meinung zu Deinen Vorschlägen äußern und Verbesserungsvorschläge machen können. Gehe die Abstimmung nicht zu direkt an.

Mache möglichst viele Leute auf Deinen Vorschlag aufmerksam, indem du z.B. eine Mail an die tagging mailing list sendest, nicht an die talk list.

Status „Vorgeschlagen“

  • Wenn das Ideen vollständig auf der Seite niedergeschrieben sind, setzt man den Status auf „Vorgeschlagen“ (Proposed in der Vorlage).
  • Man muss die Tagging-Mailingliste abonniert haben, um die nächsten Schritte auszuführen. Man sollte die Nachrichten der Liste abonnieren, bevor man eine Nachricht an die Liste sendet.
  • Senden eines RFC (Request For Comments (en)) an die Tagging-Mailingliste (tagging, “ат”openstreetmap.org).
  • Betreff: Feature Proposal - RFC - (Feature Name)
  • Der Text sollte einen Link auf die Proposal-Seite beinhalten. Außerdem ist eine „Definition“ des Proposals einzufügen.
  • Das rfcStartDate wird auf das aktuelle Datum gesetzt (2024-11-21).
  • Nun findet die eigentliche Diskussion mit den Anderen statt. Möglicherweise müssen Änderungen vorgenommen werden.
  • Jedes Proposal sollte auf seiner eigenen Seite diskutiert werden.

Abstimmung

  • Auch während der Abstimmungsphase muss man die Tagging-Mailingliste abonniert haben.
  • Frühestens zwei Wochen nach der RFC-Nachricht und wenn keine ungeklärten Fragen übrig sind, kann man einen Aufruf zur Abstimmung ("Request for Voting" (en)) an die Mailingliste senden.
  • Betreff: Feature Proposal - Voting - Feature Name
  • Der Status sollte zu Voting geändert werden.
  • Zusätzlich sollten voteStartDate auf das aktuelle Datum gesetzt werden.
  • voteEndDate soll 14 Tage vordatiert werden (voteEndDate=2024-12-05).
  • Am Ende der Seite sollte Folgendes eingefügt werden:
== Voting ==
{{Proposed feature voting}}

<!-- Cheat sheet:
{{vote|yes}} OPTIONAL MESSAGE HERE --~~~~
{{vote|no}} YOUR REASONS HERE --~~~~
{{vote|abstain}} YOUR COMMENTS HERE --~~~~

Place your vote below. -->
  • Auf der Seite sollte sich nur noch genau ein Proposal befinden, welches nicht mehr geändert werden sollte, damit klar ist, worüber abgestimmt wird.
  • Im Fall von ausbleibenden Reaktionen innerhalb der zwei Wochen, sollte der Abstimmungszeitraum verlängert werden und eine weitere E-Mail zur Mailingliste geschickt werden.
  • Die Abstimmenden sollten Ablehnungen begründen oder Alternativen vorschlagen. Letzteres ist die bessere Option.
  • Eine Übersicht über laufende Abstimmungen findet sich unter der Kategorie Proposals mit Status „Abstimmung“(en).

Nach der Abstimmung

  • Wenn die Zeit fehlt, das Proposal nach der Abstimmung aufzuräumen, ändert man den Status zu Post-Vote.
Unter Category:Proposals without post-vote cleanup finden sich alle Proposals, die aufgeräumt werden müssen, falls man Zeit hat...
  • Nach Ablauf der Abstimmung, fertigt man eine Zusammenfassung derselben an, indem man die Vorlage {{Proposed feature voting}} ausfüllt.
{{Propoosed feature voting
 | closed = yes
 | yes =                           (Anzahl Befürwortende) 
 | no =                            (Anzahl Ablehnende)
 | abstain =                       (Anzahl Enthaltungen)
 | result = approved / rejected    (Ergebnis)
 | comment =                       (Kommentar: Plädoyer, Erklärung des weiteren Vorgehens...)
}}

Zustimmung

Wenn das Proposal genug Zustimmung erreicht hat, kann man den Status auf Approved setzen.

Eine Abschätzung für „genug Zustimmung“ ist eine einstimmige Zustimmung bei mindestens acht Stimmen oder zehn Stimmen mit mehr als 74-prozentiger Zustimmung. Andere Faktoren wie die gegenwärtige Benutzung der vorgeschlagenen Eigenschaften können auch herangezogen werden. Alle Vorschläge sollten reflektiert werden, bevor das Ergebnis festgelegt wird.
Um eine Ablehnung durch fehlende Abstimmungsteilnehmer zu verhindern, kann es nützlich sein, eine weitere E-Mail zur Tagging-Mailingliste zu senden.
Hinweis zu alten Vorschlägen: Bis zum März 2015 wurde eine einstimmige Zustimmung von mindestens acht Beteiligten oder eine 50-prozentige Zustimmung bei mindestens 15 Beteiligten zum Beschließen gefordert. Solche Vorschläge bleiben weiterhin akzeptiert, da sie nach den damaligen Bedingungen bestätigt wurden.

Aufräumen des Proposals:

  • Die Seite sollte nicht verschoben werden!
  • Eine Dokumentation sollte angelegt werden:
    • Eine neue Seite für die Eigenschaften sollte angelegt werden. Die entsprechende Vorlage der Kategorie Category:Features template sollte benutzt werden. Auf der Seite DE:Key:highway findet sich ein gutes Beispiel.
    • Die neue Dokumentation sollte einen Verweis auf das Proposal beinhalten (z.B. mittels {{ValueDescription|statuslink= Proposal-Seite }}).
    • Das ursprüngliche Proposal sollte archiviert werden, indem der Inhalt mit der Vorlage {{Archived proposal}} ersetzt wird. Eine weitere Erklärung dazu findet sich in deren Dokumentation.
  • Aktualisiere die Übersicht der Karteneigenschaften:
    • Füge die neue Eigenschaft in die Übersicht von Map Features ein (deutsche Übersetzung nicht vergessen).
    • Lösche keine Einträge von Map Features, auch wenn das Proposal einen Ersatz dieser Einträge mit anderen Eigenschaften vorsieht. Das gilt als schlechter Stil, insbesondere dann, wenn die alten Eigenschaften noch verwendet werden. Werden sie jedoch nicht verwendet, können sie entfernt werden (siehe Deprecated features(en)).

Ablehnung

Wenn die Abstimmung keine Zustimmung ergibt, kann der Status auf „Abgelehnt“ gesetzt werden (rejected(en)).

  • Die Gründe sollten auf der Proposal-Seite vermerkt werden.
  • Abgelehnte Proposals können erneut zur Abstimmung gestellt, geändert und einem weiteren RFC-Prozess unterzogen werden.

Status „Aufgegeben“, „Abgesagt“, „Obsolet“, „Undefiniert“

  • Der Status eines Proposals sollte zu „Aufgegeben“ geändert werden, wenn sie lange (mindestens drei Monate) keine Änderungen im Wiki gesehen haben (unter Beachtung aller Sprachversionen und entsprechender Diskussionsseiten) und nicht in OpenStreetMap verwendet werden. Ein lange unverändertes Proposal kann durchaus täglich benutzt werden und somit nicht aufgegeben sein.
  • Die oder der Vorschlagende kann das Proposal beenden, indem er/sie den Status „Abgesagt“ (cancelled) festlegt.
  • Proposals, die durch andere obsolet geworden sind, erhalten den Status „obsolet“ (obsolete).
  • Weitere Proposals, deren Status nicht klar ist, werden unter „Undefiniert“ klassifiziert (undefined).

Nicht vorgeschlagene Eigenschaften

Nicht vorgeschlagene Eigenschaften sind Eigenschaften, die den hier beschriebenen Vorschlagsprozess nicht durchlaufen haben.

Obwohl OpenStreetMap ein sehr offenes Datenmodell besitzt, was bedeutet, dass man neue Eigenschaften festlegen kann, ohne eine Erlaubnis einholen zu müssen, gibt es einige Gründe, die Karteneigenschaften zu verwalten:

  • Die Wiki-Seite gilt als Grundlage für neue Projektmitglieder und sollte daher klar und selbsterklärend sein.
  • Konflikte und Duplikate können mittels des Proposal-Prozesses vermieden werden.
  • Kategorien und Übersichten sollten kurz gehalten werden, um ein unkontrolliertes Wachstum von Eigenschaften zu vermeiden.

Wenn man selbst ungünstige Eigenschaften findet, kann man diese mit Template:Key stub, Template:Tag stub oder anderen DE:Wiki labels versehen.

Im Allgemeinen sollte das Eintragen neuer Schlüssel auf die Seite Map features immer abgesprochen werden. Damit viele Benutzer daran teilnehmen, insbesondere wenn es sich um neue Werte für häufig genutzte Schlüssel wie highway=* handelt, sollte diesem Prozess gefolgt werden. Neue Attribute, welche andere ersetzen sollen, bedürfen ebenfalls einer Diskussion.

Übersichtsliste von Vorschlagstatus

Hinweis: Hier werden nur die Status der Vorschläge beschrieben. Status von Tags sind hier beschrieben.

Siehe auch: DE:Tag status

Versionsgeschichte des Proposal-Prozesses

Die Versionsgeschichte findet sich unter hier (so wie bei allen anderen Seiten auch).

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=DE:Proposal_process&oldid=2596620"