Proposal Tool

mein senf zu den alles zu regeln müßen fans:

https://www.youtube.com/watch?v=rAmly2pl6ZA

grüße von lutz

Leider ist eine kurze Diskussion, insbesondere wenn Sie auf an einem Themengebiet interessierte User beschränkt ist, oft unzureichend, um ein gutes Schema zu entwickeln. Oft ist da eine breitere Diskussion unter Einbeziehung von Usern aus anderen Themenbereichen und auch anderen Ländern nötig. Dies sehe ich eigentlich als den wesentlichen Nutzen der Proposals. Leider findet diese Diskussion meist erst in der Votingphase statt. Aus diesem Grunde ist es auch sehr problematisch, dass viele Proposals nie in die Votingphase gebracht werden. Zumeist wohl, weil die Abstimmungsregeln keine Aussicht auf Erfolg zulassen. Sowie es mehrere mögliche Lösungsansätze für ein Problem gibt, sind 75% Zustimmung für eine Lösung eher unrealistisch.
Statt das Proposal ins Voting zu bringen, wird dann versucht auf Basis des unausgereiften Schemas Fakten zu schaffen. Dies ist zwar verständlich aber auch problematisch.

Ein weiteres Problem ist, dass es oft nicht möglich ist, einfach ein neues besseres Schema zu mappen, ohne erhebliche Probleme für Datennutzer zu erzeugen. Es funktioniert eigentlich nur in Themengebieten, die bisher nur geringfügig gemappt wurden.

Dies ist zwar generell sinnvoll, setzt aber auch voraus, dass man fähig ist, die Entscheidung zum Refractoring zu treffen. Dazu scheint mir OSM derzeit nicht wirklich fähig zu sein, und dass es einfach mal jemand macht, verhindert die Automated Edits Policy. Es ist ja schon ein Problem, wenn sich nur mal der Name eines Tags ändern muss.
Bei der Softwareentwicklung würde man das Refractoring auf eine kurze Phase beschränken. Bei OSM wird dies dann eher endlos ausgedehnt, so dass die verursachten Probleme maximiert werden.

Das Beispiel “hinkt”, denn auch agile Softwareprojekte haben klare Regeln, ein definiertes Vorgehensmodell, definierte Termine und Ergebnistypen. Und auf keinen Fall sind sie “regel- oder architekturfrei”. Vielmehr sind auch von “agilen” Projekten die allgemeinen Software-Regeln und Architekturvorgaben des Unternehmens einzuhalten.

Recht hast du natürlich mit dem Punkt, daß man es mit den Regelungen nicht übertreiben sollte. Hier kann man sich m.E. gut an der 80:20-Regel orientieren … so wenig wie möglich, aber soviel wie nötig. Das durch jede neue Regel gleich die “Freiheit des Mappers” bedroht ist / sein könnte, kann ich nicht erkennen.

Fehlende Regelungen hingegen stellen viele vor Probleme: den Mapper, den Renderer, den Datenauswerter, …

Gruß Klaus

Dabei haben ja gerade die Teilnehmer an diesem Forum einen Hauptanteil daran, dass die Diskussion nicht mehr an einem zentralen Ort (tagging-Mailingliste) stattfindet…

Genau! Wir brauchen einen Ort, wo wir sowas diskutieren:

Warte, ich hab da schon wieder nen XKCD für:

hehe, korrekt, aber wir haben ja erst ca 5, also kann man ruhig nochmal einen versuchen :slight_smile:

Klar, die Gefahr muss man natürlich beachten, irgendjemand hat hier aber auch in einer Signatur soetwas stehen wie “wir wissen nicht, ob es besser wird, wenn sich etwas ändert, aber wenn sich nichts ändert, wird es auf jeden Fall nicht besser”. Das sollte man sich auch immer mal zu Herzen führen. Aber ich will jetz kein Comic/Sprüche Diskussion aufmachen.

Ein Problem, warum auch viel hier im Forum diskutiert wird, ist einfach die Sprachbarriere. Daran wird man acuh ncihts ändern. Zudem kommen manche Leute besser mit Mailingliste klar, andere besser mit Foren (als Abhilfe dafür, würd ich mich zum Beispiel freuen wenn dieses Forum wie nabbler die Mailinglisten integrieren könnte…).

Das Beispiel von der Votingplattform zeigt ja auch, dass es nicht einfach ist soetwas neu zu etablieren. Das ist auch ein Grund warum ich es nicht für so toll finde, wenn Einzelpersonen solche Projekte stemmen wollen.