DE:Proposal process

From OpenStreetMap Wiki
(Redirected from DE:Creating a proposal)
Jump to: navigation, search
Verfügbare Sprachen — Proposal process
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް

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.

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, daß 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 Geografie-Student möchte vielleicht in einer bestimmten Region die Gesamtfläche aller Nationalparks erfassen.
  • Ein Soziologie-Student 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 Geschichts-Student möchte vielleicht darstellen, wo überall in einem bestimmten Krieg Schlachten stattfanden.
  • Hilft das 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.

Erstellung einer Proposal Seite

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

Entwurf eines Proposals

Man kopiere den folgenden Text 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]].

Nun 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.
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").
  • 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 (JJJJ-MM-TT).
  • 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 und voteEndDate 14 Tage vordatiert werden.
    Am Ende der Seite sollte folgendes eingefügt werden:
== Voting ==
{{Template: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 eventuell 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. In ihrer Dokumentation findet sich eine Anleitung dazu.

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.

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 Vorlage {{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 {{Features template|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“ festlegt.
  • Proposals, die durch andere obsolet geworden sind, erhalten den Status „obsolet“.
  • Weitere Proposals, deren Status nicht klar ist, werden unter „Undefiniert“ klassifiziert.

Nicht vorgeschlagene Eigenschaften

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.

Versionsgeschichte des Proposal-Prozesses

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