On Thu, 12 Mar 2009, Markus wrote:
Problematisch sind die Schnittstellen:
- wie erfährt der Entwickler, was der Anwender braucht?
Der Anwender schreibt einen Bugreport und sagt welche Probleme er hat.
Oder er schreibt es in eine Forum und jemand anders erstellt den
Bugreport.
- wie erklärt der Anwender dem Entwickler was er meint?
Er anwortet auf die Fragen hinsichtlich seines Reports.
- wie erklärt der Entwickler dem Anwender wie es funktioniert?
Gar nicht. Das ist nicht seine Aufgabe. Er/ich soll entwickeln. Wenn ich
Andwenderschulung mache habe ich keine Zeit zum Entwickeln.
- wer entscheidet über die Wertigkeit von Wünschen, Ideen, Konzepten?
Die Anzahl der Leute, die sich bei spezifischen Bugreports beteiligen und
der Entwickler, der es umsetzt.
- wie werden Erkenntnisse geteilt und verwertet?
Im Bugreport bildet sich nach und nach ein Konzept für die Umsetzung
heraus oder eine Konsens welcher Art auch immer.
- wie werden Verbesserungsideen kommuniziert?
Derjenige, der eine Idee hat schreibt einen Bugreport. Siehe oben.
Das kann man mögen oder nicht, aber ändern kann man es nicht.
Doch Dirk, man kann (fast) alles ändern!
Nein, kann man nicht. Das hat nichts mit OSM zu tun. Das ist überall so.
Jeder der versucht die Menschen oder Verfahren zu verbessern wird
scheitern solange er die menschliche Natur nicht in Betracht zieht. Und
wenn es niemanden hinreichend interessiert, wird es auch keiner machen.
Wie gesagt, du kannst finden, dass das nicht schön ist, aber ändern
kannst Du es nicht.
Alternativ empfehle ich in "Bill Brysons - Eine kurze Geschichte von fast
allem" (ein sehr gutes Buch) den Abschnitt über die Klassifizierung von
Lebewesen. Zeigt das gleiche Problem in einem ganz anderen Umfeld.
Ich hatte sie geschrieben weil es keine gab.
Meine Methode war Versuch und Irrtum.
Und, was ist daran falsch? Jetzt kannst Du es besser weil Du dazugelernt
hast.
Das war alles andere als lust- oder sinnvoll.
Und den Softwareentwicklern würde es Lust machen? Mir jedenfalls nicht.
Ich habe es getan, weil ich es Scheisse fände, wenn jeder diesen Prozess
selbst durchlaufen müsste.
Das ist schön, ändert aber nichts daran, dass es ohne Fortführung veralten
wird. Das ist aber nicht die ganze Wahrheit. Deine Motivation war
höchstwahrscheinlich Anerkennung der dafür aufgebrachten Arbeit. Und jetzt
entsprechende Enttäuschung darüber, das es scheinbar doch keiner zur
Kenntnis nimmt.
Das mit dem Aktualisieren stelle ich mir so vor, dass die Entwickler
ihre Änderungen einfach jeweils dokumentieren.
Nein. Die Programmierer haben dazu keine Zeit.
Du kennst den Vergleich mit den Waldarbeitern,
die keine Zeit haben ihre Säge zu schärfen?
Der Waldarbeiter hat genausowenig Lust nach getaner Arbeit duzende
Formulare auszufüllen, wie ich und die meisten anderen Programmierer Lust
haben zu dokumentieren. Denn wie ich schon sagte - die
Entwicklerdokumentation (in deinem Beispiel die Säge schärfen) ist
vollständig.
Eine Verbesserung ist nur dann wirklich eine, wenn sie auch beim
"Kunden" ankommt. Sie ist dann keine, wenn er mehr Energie aufwenden
müsste um sie sich zu erarbeiten, als er Energie dadurch einsparen würde.
Vielleicht sollte ich Dir das Konzept von OpenSource nochmal ins
Bewusstsein rufen. Ich mache nichts damit es bei irgendeinem Kunden
ankommt. Ich mache etwas, weil ich meine Bedürfnisse befriedigen will,
nicht die von jemand anders.
- Ich habe Spass am Programmieren
- Ich liebe klare Strukturen und intelligente Lösungen
- Ich mag es mit anderen bei einem Problem zusammenzuarbeiten
- Ich freue mich wenn jemand meine Arbeit nutzt und wertschätzt
- Ich will Geld verdienen
Zum Glück für andere decken sich meine Bedürfnisse teilweise mit denen
andere (vorletzter Punkt). Der letzte Punkt ist im OpenSource-Umfeld
nachrangig.
Wenn Du Dokumentationen haben willst, dann finde jemanden, der mit dem
Erstellen einer Dokumentation seine Bedürfnisse befrieden kann. Bei mir
klappt das nur mit dem letzten Punkt (nämlich Geldverdienen).
Wenn wir beide zusammen wohnen und arbeiten würden, wäre es
wahrscheinlich leicht für mich, Deine Arbeit zu dokumentieren.
So aber müsste ich Dich fragen, Du mir erklären, ich bei Nichtverstehen
rückfragen etc. In dieser Zeit hättest Du es schon längst geschrieben.
Das ist Unfug. Das Dokumentieren besteht aus dem Testen der Funktionalität
und dann schreiben. Eine Funktion zu dokumentieren kostet teilweise
dreimal soviel Zeit, wie sie zu schreiben. Wie kommst Du auf die abwegige
Idee, dass ich weiß wie JOSM funktioniert? Ich muss auch nachschauen und
das kannst Du auch. Ich kann nur bei komplizierten Themen etwas besser
nachschauen weil ich den Quelltext lesen kann. 99% alle Themen sind aber
nicht kompliziert.
Vorher sollten wir aber noch klären, wie wir mit der Redundanz von
http://josm.openstreetmap.de/wiki umgehen wollen und ob es nicht besser
ist, das irgendwie konsistent zusammenzuführen.
Das josm-Wiki hat einen klare Struktur. Jede Seite kann von JOSM aus
direkt aufgerufen werden, um Hilfe zu aktuellen Funktion zu erhalten. Wenn
eine Zusammenführung stattfinden soll, dann im JOSM-Wiki. Aus diesem Grund
prüfe und lese ich im normalen OSM-Wiki die Texte auch nicht, weil die
eben keine Anwenderdokumentation darstellen. Ich sorge nur dafür das
alzustark veraltete Sachen korrigiert werden.
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
_______________________________________________
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
