Hi André, *, André Schnabel schrieb:
>Hi, >mal abgesehen davon, dass im Moment Aktivitäten laufen, von >CollabNet nach Kenai [1] zu migrieren ... In der Tat verspreche ich mir davon, dass bisher große Schmerzen dadurch gelindert werden können. Beim Aufbau neuer Strukturen kann es vielleicht weniger bremsen als das bisherige System - die Konzepte liefern müssen aber wir. :o)) > Friedrich Strohmaier schrieb: >... > >> Du hast Möglichkeit 3 Vergessen: Die Kraft der Kommunity nutzen! > >prinzipiell richtig, aber ... > >> Mein Favorit: >> Mailingliste (Nr. 117 :o))): [email protected] >> dort werden Issues bewertet (und hochgezählt?) und falls würdig >> befunden in den Issuetracker eingetragen oder auch - gnädig >> vergessen. >> >> Mit dem richtigen Management könnte folgendes funktionieren: >> - Anwender werden ermutigt, Bugs an diese Liste zu melden. >> Eignungsvorraussetzung: Email schreiben >> >> - Die dort sich tummelnden Muttersprachler kümmern sich um >> "nichtenglische" Meldungen und Melder. >> Eignungsvorraussetzung: Email schreiben, englisch >> >> - Erfahrenere Projektmitglieder beobachten und bewerten die >> Meldungen und schreiben ggf. nach Absprache mit den Entwicklern >> einen Bugreport nach den Regeln der Kunst: Vorhandene Bugs prüfen >> Duplikate auffinden ... >> Eignungsvorraussetzung: Email schreiben, englisch, issuetracker. >> >> Sollte meine Wunschvorstellung wahr werden und die Liste >> einigermaßen funktionieren, werden die ersten Entwickler als >> Abonnenten nicht lange auf sich warten lassen. ;o)) >Ich glaube kaum, dass das die Lösung unseres Problems ist. Ich auch nicht - aber ich glaube, es kann ein Baustein dazu sein.. >Wie Michael ja richtig bemerkt hat, ist die Rate der Fehlermeldungen >ja schon gestiegen. Die Vereinfachung des Fehleraufgebens ist > natürlich wichtig, würde aber unser Problem nicht lösen. Nicht solange wie bisher zwar mehr Bugs eingespeist werden aber gleich wenig Leute sie verarbeiten müssen.. > Es würde es im Gegenteil verschärfen: wir würde *noch mehr* Fehler > gemeldet bekommen und *noch mehr* Informationen zu (auch unwichtigen) > Fehlern erhalten, ohne diese Informationen aber wirklich abzuarbeiten > (sprich: Fehler zu korrigieren). Ich behaupte mal kühn, dass ein großer Teil des Unbehagens nicht die Quantität der Issuebearbeitung betrifft, sondern die Richtungsbestimmung oder Priorisierung. Bei der derzeitigen Masse an unerledigten Issues halte ich eine irgendwie koordinierte Steuerung für - ähmm - extrem schwierig. Sollte mich nicht wundern wenn sehr viele Beteiligte denken oder sagen: Wir müssen diese Masse an Issues bewältigt haben, bevor wir vernünftig damit arbeiten können! Aber keiner glaubt daran, dass es in diesem Leben noch gelingen kann. >> Ein Teil des Issuetrackers würde so auf das "Projektgedächtnis" >> ausgelagert, dem im Gegensatz zum Issutracker selber "die Gnade des >> Vergessens" gegeben ist. >Auch der Issuetracker kann/könnte vergessen. Aber was hilft es, eine >Fehlermeldung tatsächlich zu vergessen, wenn sie einen Monat später >wiederkommt? Sagen wir mal so: Wenn sie in einem Issue steckt, ist sie schnell wieder aufgeweckt. Wenn sie in der Mailingliste "vergessen" ist, ist sie nur solange vergessen, bis sie erneut auf den Tisch kommt. Es widerspräche meiner Erfahrung, dass nicht irgendjemand von den Abonnenten sich erinnerte - und genau davon verspreche ich mir Einiges: Die Dinge sind nicht in einem System verborgen, das nur wenige kennen und können, sonder sie sind präsent und mit einfachen vielen Teilnehmern leicht zugänglichen Mitteln weiterzuverwerten.. >Spätestens für die Duplikatssuche wird sie gebraucht (sonst geht der >ganze Bewertungs-Rückfrage-und-Vergessen-Zauber wieder von vorne los). Ich sehe die Chancen der Duplikaterkennung und -Verwertung in einer Mailinglistenabonnentenschar mindestens genauso gut aufgehoben. >Was mir bei dem Ganzen fehlt, ist der Anreiz des "Erfolgs". Also nicht >nur "ich habe einen Fehler bearbeitet" sondern "ich habe einen Fehler >bearbeitet, der dann auch gelöst wurde". Ich verspreche mir sehr viel von einer Reduzierung offener Issues auf ein für das menschliche Erfassungsvermögen taugliches Maß. Das wird Auswirkungen auf die Issue-Priorisierung bei den Entwicklern haben und es wird mehr Raum entstehen für die Prioriesierung "ätzender" Issues. Zur Lösung eines solchen beigetragen zu haben, dürfte wirkungsvoll Hunger auf "mehr" machen.. >Sofern man sich nicht auf Showstoppper konzentriert oder den einen oder >anderen Entwickler persönlich kennt, stellt sich dieses Erfolgserlebnis >relativ selten ein. Genau das soll ja besser werden! ;o)) > Allerdings kann der sich bei "normalen" Issues auch nur einstellen, > wenn die Liste der bereits bekannten Fehler deutlich kleiner ist, als > die jetzige. Da stimme ich Dir zu. Genau das soll ja am Schluss rauskommen - und besser gelingen, als jetzt! :o)) Gruß -- Friedrich Ansprechpartner PrOOo-Box (http://prooo-box.org) .. und nicht vergessen: Flüster's den Listen! :o)) Schöne Grüße von der Sonnenalb --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
