Verwaltung der Mapping Features verbessern

Mhh das stimmt schon aber ich denke es ist zum einen der unsichere Umgang mit dem Wikisyntax und zum anderen möchte man den Lesern kurze Wege bieten also werden externe Sachen mit in das Wiki übrernommen.

Ob das Zitat passt weiß ich nicht. Auch eine Regulierung fände ich nicht schlecht, nur werden diejenigen immer permanenter Kritik ausgesetzt sein, weil sich immer jemand beschweren wird.

Eine Regulierung muss nicht sein. Das reguliert sich derzeit doch auch und ganz OSM basiert auf diesem Prinzip und es geht gut. Über eine Regulierung kann man nachdenken, wenn es nötig ist. Sprich wenn es ständig zu Edit-Wars kommt.

Dem Verbinden von unseren Definitionen mit denen von wikipedia stehe ich kritisch gegenüber. Zum einen gibt es für viele Tags mit sicherheit keine wikipedia-Definition. Zum anderen sind die OSM’er dann nichtmehr Herr über die Definition.

+1 Alles ganz genau meine Meinung.

Für OSM-Tags als solche gibt es eh keine Wikipedia-Seiten. Aber für die realen Dinge, die sie repräsentieren sollen. OSM muss natürlich seine eigene Technik (u.a. die Schlüssel/Wert-Paare) definieren, aber beim Wissen über die Welt kann man schon vorhandenes (eben bei der Wikipedia) nutzen.

Wie „Herr über die Definition" sein zu wollen dann mitunter konkret aussieht, sieht man z.B. an der englischen denomination=*-Seite. Da gibt es überwiegend überhaupt keine Definitionen und Links auf die gleiche Seite (ganz schlechte Usability). Wenn es Definitionen gibt, dann bestehen sie aus wenigen Worten, gelegentlich aus einem Link in die Wikipedia und manchmal aus Links zu der entsprechenden Propagandaseite der Sekte Webseite der religiösen Gruppierung. Na prima.

Naheliegend wäre da in der Liste jeweils durchgehend die Namen mit Links zur entsprechenden Wikipedia-Seite zu setzen. Beispiel:

Das wäre nicht im geringsten ein Verlust, denn die OSMler definieren ja eh nicht was z.B. Religionen sind, sie sammeln Geodaten.

Das Wiki ist meiner Meinung nach in einem relativ chaotischen Zustand und man liest auf User-Seiten im Wiki gelegentlich die Aufforderung sich nicht um Wahlen und Wiki-Gefummel zu kümmern, sondern zu mappen. Verständlich, aber dann soll man bitte auch damit einverstanden sein ein wenig Outsourcing zu betreiben wo es Sinn macht.

Hmm das stimmt schon, aber wenn die Seiten nur Stubs sind da sie nur Verweise enthalten ist mir selber auch nicht viel geholfen, da sie dann zum Beispiel garnicht die vielen Schlagwörter enthalten. Nichts desto trotz macht verlinken auf Wikipedia durchaus Sinn, da einige Spezialthemen und deren Abgrenzung meistens gar nicht sooooo klar für Normalsterbliche sind (z.B. bei Healthcare)

Und ja es stimmt das Wiki ist chaotisch gewachsen und nun muss man mal Grund reinbringen. Wir arbeiten ja daran :wink:

Naja, so ganz gut geht es halt eben nicht immer, deshalb gibt es ja diese Diskussion hier.

Und selbst wenn es gut waere, dann koennte man ja immer noch pruefen, ob es nicht anders besser gehen kann.

Gruss
Torsten

Zur geringen Beteiligung an Vorschlägen und Wahlen und der daraus folgenden geringen Akzeptanz des Prozesses:

Es ist auch sehr unbequem und relativ viel Arbeit sich zu beteiligen. Einerseits ist das Wiki sehr chaotisch. Ich meine es gibt keine Übersicht über die laufenden Diskussionen und Wahlen. Über die Tagging-Mailingliste kommt sehr viel Traffic. Ich habe im Moment 1216 ungelesene Mails in meinem OSM-Ordner. Für Leute, die in ihrem Mailprogramm keine Filter einstellen können, ist es zu viel.

Die Diskussion in Mediawiki ist ein Krampf. Es gibt zur Verbesserung LiquidThreads. Alternativ wäre es aber auch denkbar, dass die Diskussionslinks im Wiki in dieses Forum umgeleitet würden. (Falls das im Details keine technischen Probleme geben sollte.)

Aber auch wenn es wesentlich einfacher wäre sich zu beteiligen würde das natürlich nichts an der Tatsache ändern, dass die meisten OSMler lieber Geodaten sammeln statt sich an endlosen Diskusssionen zu beteiligen.

Eine denkbare Lösungsmöglichkeit wäre Delegated Voting / Liquid Democracy. Die Idee ist, dass man sein Wahlrecht auf andere Leute abgeben kann, und zwar sehr fein abgestimmt und nur solange man will.

Dazu gibt es auch die sehr interessante Podcast-Folge CRE 158. (Dieser Podcast ist allgemein sehr empfehlenswert. Es gibt auch eine OSM-Folge, durch die ich auf OSM aufmerksam geworden bin.) Und auf dem letzten CCC gab es einen Vortrag, den man sich als Video ansehen kann.

Hmm die Frage ist ebend ob man unbedingt an den Abstimmungen festhalten will. Für mich persönlich ist der eigentliche Zweck, dass die Leute “gezwungen” werden Ihre Ideen zur Diskussion/Verbesserung zu stellen. Selbst wenn alle abstimmen würden, was würde uns das für ein Proposal bringen?

Die Hinweise sind gut und ich denke eine Verbesserung der Kommunikationsform ist ein wichtiger Schritt. Ich vermute dass aber auch dann nicht so viel mehr Leute am Designen von Features mitmachen, schlichtweg weil es zu viel Zeit frisst und teilweise auch auf sehr filigrane Details eingegangen wird, die der Lösung nicht unbedingt zuträglich sind. Einige würden aber bestimmt mitmachen, wenn man ihnen einen Entwurf für ein Feature hinlegt, dass sie interessieren könnte. Also ist auch die benachrichtigung ein wichtiger Punkt.

Irgendwie habe ich das Gefühl, mit OSM geht es nicht weiter. Es findet einfach keine Evolution statt. Das ewige Lizenzgezeter ist ein typisches Beispiel dafür. Es scheint als wenn OSM Angst vor einer Professionalisierung hätte. Dies kann man jedoch nicht verhindern, wie es Wikipedia nicht verhindern konnte. Man kann es allerhöchstens etwas hinausschieben, und man kann es jetzt noch gestalten und beeinflussen.

Aber auch hier geht es kaum einen Schritt vorwärts. Man ist nicht mal fähig, sich auf eine Dokuemntation der Eckpunkte zu einigen. Ich will nochmals die Eckpunkte in etwas geänderten Form auflisten:

  1. Jede angemedete (und damit bekannte) Person darf Objekte nach seinem Dafürhalten in OSM eintragen. Sämtliche Einträge gelten immer weltweit und sind in englisch.
  2. Löschungen sind grundsätzlich nur erlaubt, sofern es a) Kleinigkeiten sind oder b) im Forum und in der Mailinglist bekanntgemacht wurden.
  3. Als Entscheidungsmittel für das Dokumentieren von Einträgen in den A-Z_Features dienen die ProposedFeatures. Das Verfahren ist wie bisher.
  4. Die A-Z_Features erklären alles (dokumentiert), was wie sinnvoll zu mappen ist. Es können auch Hinweise darin stehen, die nicht allgemeingültig sind, sie müssen aber so bezeichnet sein. Bei jedem Feature wird angegeben, ob darüber in den ProposedFeatures abgestimmt wurde oder nicht.
  5. Was im .Standard-OSM-Renderer. in die Renderer-Regeln aufgenommen und angezeigt werden sollte, wir in den A-Z_Features angegeben.

Ich habe übrigens ganz bewusst die A-Z_Features als alleiniges Dokumentationsmittel bezeichnet. Es muss von Grund auf neu festgelegt werden (Template), damit es einen einheitlichen Aufbau entspricht. Auch kann so jedes Feature, das eine minimale Relevanz hat dokumentiert werden. Die MapFeatures können so irgendwann aufs Altenteil gesetzt werden. Bis die A-Z_Features bereit sind, dienen die MapFeatures als Platzhalter dafür.

So damit ist eigentlich alles gesagt, was es dazu zu sagen gibt. Es kann nun jeder seine Meinung dazu bekunden, ich werde mich erst wieder daran beteiligen, wenn ich etwas in der Art auf der Hauptseite des OSM-Wiki sehe.

Wyo

Ich kann Punkt 2 nicht zustimmen. Es ist Grundsatz von OSM, dass jeder erstmal tun und lassen kann, was er will. Und wenn jemand es für sinnvoll hält, etwas zu löschen, auch wenn es keine Kleinigkeit ist und er das nirgends bekannt geben will, soll er das tun. Wenns Mist war, muss es halt rückgängig gemacht werden. Hat bis jetzt immer gut so funktioniert und wird es auch weiter tun. OSM in Regeln pressen zu wollen, wird den selben Effekt haben wie bei der Wikipedia - hinterher will keiner mehr mitmachen, außer Blockwarten, die auf ihren (und fremden) Eintragungen sitzen und keine Änderung akzeptieren. Und über MapFeatures wird bei uns nunmal auch mit den Füßen abgestimmt - durch Verwendung oder eben nicht. Der Proposal-Prozess dient nur dazu, dass erstmal jeder seinen Senf dazugeben kann, damit auch Dinge bedacht werden können, die dem Vorschlagenden nicht eingefallen sind.

@wyo Danke für deine Meinung, aber bockig sein bringt uns doch nicht weiter, sondern machen :wink: Es wird im großen nichts passieren, wenn wir im deutschen Raum nicht mal loslegen. Da draußen gibt es keinen, der dazu stellung bezieht, dass liegt alles an uns ob wir das ändern möchten oder nicht. Und du sagst ja selber du möchtest, dass sich etwas ändert :slight_smile:

Dein 4. setzt vorraus dass dieser Prozess funktioniert, was er aber ja leider nicht macht. Es gibt so viele tote Proposals an denen sich keinen vergreifen möchte und es gibt auf den Map Features Einträge über die nicht abgestimmt wurde.

Ich finde Jochens neues Taginfo Tool sehr gut um sich über die Verbreitung/Unterstützung von Tags zu informieren aber gerade für Newbies ist es für den Erstkontakt zu unübersichtlich http://wiki.openstreetmap.org/wiki/Taginfo

Das hat nichts mit bockig sein zu tun. Wenn ich in der Freizeit etwas mache, dann soll es Freude machen und wenn es keine mehr macht, dann suche ich mir ein anderes Betätigungsfeld.

Trotzdem sollte es so so dokumentiert werden. Es war mal dafür gedacht und ich finde es eigentlich gut so. Jedenfalls besser als Wild West.

Wyo

I would say not a good Idea to mark Non-proposed features because it gives the false impression all all tags nee to be proposed. So instead of marking them Not-proposed, I am proposing a new idea to mark features that have been
discussed, agreed, and are in standard practice of marking the OSM map.

http://wiki.openstreetmap.org/wiki/Blue_Ribbon_features

Here is the definition:
Blue Ribbon Features Are map features that have gone though the proposal
process. They have been discussed and found by the OSM community to be a
standard way to mark a map feature.

The Blue ribbon is a way to certify a tag/key/relation is being used in standard
practice of marking the OSM map, and has taken proper steps to be discussed and
agreed upon by the OSM community.

The reason for this proposal comes from the ongoing debate of the proposal
process. Even though it is acceptable to document eny tag used on OSM, I think
this would be a positive way to show a feature has gone thought the proposal
process and that it is considered safe to use to mark the map by the OSM
community.

Please take time to consider the positives of this proposed label

  • Promotes the use of Proposed features for better definitions and
    documentation.
  • Gives users assurance that a tag is widely used.
  • Will define better that the proposal process is not mandatory, but help full
    in getting community support.

Thanks, Nickvet419

Another nice idea :slight_smile:

Finde ich auch eine gute Idee.

Ist eine Art Qualitätssicherungs-Siegel.

Denke aber es sollte erweitert werden um, dass es eine aussagekräftige Wiki-Seite zu dem Feature gibt.

Man sollte vielleicht darüber nachdenken, dass es eine max-TTL (TTL → Time to Life → maximale Existenzzeiot des Proposals) für Proporsals geben sollte.
Diese sollte durch denjenigen definiert werden der das Proporsal hervorbringt und auf der Proposal-Seite als Spalte auftauchen.

Ist die überschritten und wurde nicht erhöht scheint sich niemand mehr um das Proporsal zu kümmern und es wird gelöscht.

Zum Nicht-Anerkennen von Proposals ist eigentlich zu sagen, dass ein Proposal anerkannt werden sollt sobald die Vote-Time um ist und sich eine mehrheit für das Feature ausgesprochen hat.
Mit Mehrheit ist eine 50%-Mehrheit gemeint, daraus folgt wenn es nur einen gibt der Abstimmt und keine Ggenstimmen gibt, dann ist diese Meinung bereits die Mehrheit und damit am Ende des Voting-prozesses ausschlaggebend.

Letztendlich (auch wenn OSM ein Freizeitprojekt ist) sollte jedes OSM-Mitglied regelmäßig (1 mal pro Monat??) die Proposal-Seite durchlesen und entsprechend Votes abgeben.

Allgemein ist zu überlegen ob das Voten nicht einfacher gestaltet werden kann (Anmelden → Stimem agebene, gegebenfalls Kommentar) als es jetzt über die Wiki-Software läuft.

Zu oben stehnder Meinung mit dem Abstimmen bin ich gekommen da ich bei den meisten Proposals nur sehr wenige Votes sehe, im Forum aber viel gemeckert wird.

Diese Proposals sind aber eigentlich genau dafür gedacht bestimmen zu können welche Feature als technisch Sinnvoll (>technisch< habe ich mit Absicht geschrieben) zu erfassen sind und ob es vielleicht schon durch andere Tags abgebildet werden kann.

Die Proposals sind eine Möglichkeit der demokratischen Mitbestimmung und Diskussion.

Hmm naja aber bei dem meckern wird ja meistens das Design kritisiert. Also ist denke ich das was die Leute wollen nicht dass sie um Zustimmung gefragt werden (groß Zeit will ja auch verständlicher Weise keiner investieren) sondern dass man in den Prozess des Designs mit einbezogen ist, oder?

Mag sein, das Problem dabei ist aber wenn man einen Vorschlag für ein nues Feature macht kommen hundertausend Kommentare.

Zum Teil heißt es dann das das Feature nicht notwendig ist, es überhaupt nicht notwendig ist das zu taggen oder das es mit der Art und Weise des Taggens Probleme geben wird.

So, dann hat man sehr viele Meinungen.

Daraus versucht man als Vorschlagender etwas zu machen, was man meint der Meinung der Mehrheit zu entsprechen.

Und dann?

Wie geht es dann weiter, woher weiß ich, dass das was ich mir denke dann tatsächlich auch von der Mehrheit so unterstützt wird oder so gesehen wird?

Wenn nicht abgestimmt wird haben wir das Problem das wir uns das Tagging zerfasern, weil es unter Umständen keinen Konsens gibt wie etwas getaggt wird.

Dann gibt es hundertausend Varianten.

Daher sehe ich die Abstimmungen als wichtig an.

Das Problem ist, dass die Vorschläge primär auf den Listen oder im Forum diskutiert werden. Das wird man auch nicht ändern können.

Es ist dann ein großer Aufwand, das ganze neben der internationalen Diskussion auf tagging noch ein proposal zu schreiben. Das ist evtl. noch sinnvoll, wenn man eine ganze Klasse (Bspw. Handwerker) ausarbeiten will. Aber bei einer Erweiterung von shop=* um einen neuen Wert für ein XY-Geschäft lohnt der Aufwand nicht.

Das ganze relativiert sich dann noch, da die Abstimmung von sehr wenigen gemacht wird. Das ganze ist auch verständlich. Der normale Mapper kann und will nicht rund um die Uhr alle Diskussionskanäle überwachen etc. Die wiki-Seite des Proposals verläuft im Sand, nach ein paar Wochen gibts dann eine Abstimmung von ein paar Leuten. Der Prozess ist viel zu umständlich und langwierig und wird zur farce, wenn es in dem Zeitraum seit der ersten Diskussion längst angewendet wird und zum Zeitpunkt der Abstimmung schon längst etabliert ist. Zudem gibt es min. 3 Diskussionen zum gleichen Thema, wobei fraglich ist, ob alle Argumente überall einzugerhalten.

Wenn man eine Abstimmung machen will (was ich durchaus begrüße), dann sehr Zeitnah. Der Tag wird in den allgemeinen Diskussionskanälen Diskutiert, auf tagging veröffentlicht und zur Abstimmung gestellt.

Wobei dieser Abstimmung immer noch der “Volksentscheid” der Mapper im Weg stehen kann… :wink:

@Mailerdaimon Ich würde es so sehen, dass das Design dann zumindest einen Stand hat, der den Kritikpunkten entspricht. Im Schlimmsten fall ist dem nicht so, dann werden sich die Leute aber davon abwenden bzw. irgendjemand anderes fuxt die Unzulänglichkeit dann so, dass er einen besseren Vorschlag einreicht.

Das mit den vielen Meinungen stimmt schon. Nur denke ich ist es weniger dramatisch, da man ebend ein Gefühl dafür bekommt wer nur auf seiner Kritik beharrt und wer konstruktiv mitdiskutiert und dann vielleicht das Proposal sogar mitgestaltet. Es sind ja nicht sooooo viele, die sich aktiv am Design neuer Tags beteiligen (ML, dann und wann Forum).

@aighes
Es stimmt so ein Proposal ist ein großer Aufwand. Aber man benötigt ja eh noch eine Doku für andere Mapper. Doku ist etwas was Foren und Mailinglisten nicht gut bieten können.

Das mit dem zeitnah finde ich auch wünschenswert, denke aber dass es schlichtweg an den Kapazitäten/Zeit dafür mangelt. Da gibt es zu viele Kanäle und Meinungen die abgeglichen werden müssen. Einen ersten Schritt in die Richtung ist sicherlich der Wochenrückblick und die Community Updates, so dass man als Otto Normal Mapper auch mitbekommt wenn ein interessantes Tag erscheint.