Re: [de-discuss] [bug-per-mail] Eine weitere Idee, wie man Bugs melden kann

Hallo,

Versuch einer Zusammenfassung der bisherigen spannenden und sehr 
sachlich geführten Diskussion (ohne Anspruch auf Vollständigkeit):

IHMO gibt es drei Problemfelder:
1) Identifikation eines Bugs und Bereitstellung vollständiger 
Informationen dazu
2) Durchführung einer Bugreport-Erstellung
3) Abarbeitung erstellte Bugreports

zu 1)
hier könnten wir IMHO einen Prototyp schaffen (was  Florian R. zurzeit 
versucht, umzusetzen) - und zwar (zunächst) nur deutschsprachig.
Noch ungeklärte Frage: wo soll die Mail hingeleitet werden bzw. wer soll 
diese bearbeiten. Vielleicht erklärt sich Florian R. bereit, dies zu tun.
IMHO besteht durch diese Vorgehensweise jederzeit die Möglichkeit, aus 
dieser Nummer ohne Schaden für das Projekt wieder aussteigen zu können. 
Dies sollte IMHO eine Grundforderung sein.

zu 2)
Dies ist eng mit 1) verbunden. Vielleicht sollten wir die Anleitung auf 
dem WIKI optimieren und bei Bedarf bei Anfragen posten bzw. die 
Anleitung auch auf der TDF-Webseite veröffentlichen.
Ich gebe zu Bedenken, dass Anwender wahrscheinlich öfters Bug melden 
würden, wenn dies einfacher gehen würde (erwünschter Effekt). 
Andererseits besteht die Gefahr, dass die falsch positiven Bugmeldungen 
zunehmen werden (unerwünschter Effekt).

zu 3)
Ich halte die Idee einer virtuellen deutschsprachigen 
Bug-Review-(Lern-)Woche für sehr spannend. Vielleicht nicht eine "Woche" 
im engen Sinne, sondern eine zeitliche Phase, in der ein Thema an einem 
konkreten Beispiel abgearbeitet wird. Mir fallen da spontan z.B. 
"Identifikation eines Bugs und Bereitstellung vollständiger 
Informationen dazu, "korrekte Darstellung eines Bugreports", "von 
UNCONFIRMED zu CONFIRMED" oder "Duplikate finden und als solches 
kennzeichnen" ein.
Hier muss IHMO aber ein erfahrener "Tutor" diese Woche(n) begleiten.

Gruß

Jochen



Am 19.02.2012 14:38, schrieb Nino Novak:
> Hallo alle,
>
> Am Sonntag, 19. Februar 2012, 13:29:30 schrieb Christian Lohmaier:
>
> > > IMHO müssen wir uns folgende Fragen stellen bzw. beantworten:
> > > 1) Wo soll das Formular eingestellt werden?
> > > 2) An welche Adresse soll die Anfrage geleitet werden?
> >
> > Viel wichtiger: (und ja, ich wiederhole mich)
> > * Wer kümmert sich um die Anfragen, wer bearbeitet sie?
> >
> > ...
> >
> > Deshalb nochmals der Aufruf:
> > Beteiligt euch erstmal am internationalen Bugreview - das müßt ihr ja
> > zusätzlich zu der Übersetzung eh machen.
>
> +1
>
> Ein deutschprachiges Formular kann schon hilfreich sein, jedenfalls könnte es
> diejenigen dazu ermutigen, einen Fehler zu melden, die sich bisher mit der
> Begründung "verstehe Bugzilla nicht" (oder so ähnlich) davor gedrückt haben.
>
> Aber wie Christian sagt, jemand muss sich dann auch um die anfallenden
> Berichte kümmern/gegenfragen/ausdiskutieren/den Fehler eingrenzen usw.
>
> Vorschlag daher:
> Wie wäre es vorab mit einer deutschsprachigen Bug-Review-(Lern-) Woche?
>
> Zu der könnte - nicht nur spaßeshalber, sondern auch weil das das Lernen
> gemeinsam durchaus besser klappen kann als wenn das nur 1-2 Hansel alleine
> machen - die gesamte deutschsprachige Community eingeladen werden. Sozusagen
> als Fortsetzung des QA-Wochenendes auf virtueller Ebene ;-)
>
> (Und als Ergänzung zur Bug-Hunting-Session der Beta- und Release Candidate-QA)
>
>
> Dabei würden im besten Fall
> a) die Schwierigkeiten des QA-Prozesses allen Beteiligten deutlicher werden,
> b) wenn sich das Ganze "auf deutsch" abspielt, wäre eine Hürde weniger da und
> würde vielleicht sogar mehr/andere Leute anlocken. Außerdem
> c) wäre dadurch schon eine "notwendige Voraussetzung" zum deutschsprachigen
> QA-Formular angepackt, damit wäre man diesem zumindest mal insgesamt einen
> Schritt näher! Und schließlich
> d) könnten vielleicht wieder ein paar UNCONFIRMED-Bugs weniger dabei
> herausspringen, was ja an und für sich eine gute Sache ist ;-)
>
> (Man müsste sich nur einen guten Zeitpunkt überlegen, denn die 3.5.1-Linie
> wird bereits demnächst "eingefroren", d.h. dafür ist es schon zu spät,
> andererseits dauern Bugklärungen eh eine Weile, d.h. das Ganze könnte als Ziel
> die 3.5.2 haben, die 4 Wochen später eingefroren wird.)
>
>
> > Klar, wenn man die schwierigen Sachen einfach ignoriert und nach
> > /dev/null schiebt, dann ist es kein Problem, aber dann braucht es auch
> > das Formular nicht.
>
> (dem wäre mit obigem Vorschlag z.B. auch besser beizukommen)
>
>
> Und noch dazu:
>
> > "So einfach vom Netz nehmen" ist eben nicht so einfach. Denn da wird
> > u.U. auch ein entsprechendes "Medien"echo kommen.
> > Meldung 1 - "Bugreports jetzt auch auf Deutsch möglich"...
> > Meldung 2 - "nach nur<zeitspanne>  zugemacht, zu viele Bugreports, zu
> > wenig Bearbeiter,... da waren die Ersteller doch zu sehr überzeugt von
> > der Qualität des Produkts" (füge irgenein LibO/TDF-Bashing ein, zu dem
> > der Autor einen Anlaß braucht.
>
> Könnte man dem nicht durch eine "reine Testinstallation" begegnen? Ich meine,
> warum sollten wir nicht irgendwelche Ideen an Prototypen austesten, das muss
> ja dann nicht gleich jedes Mal zu einer festen Einrichtung werden, das können
> auch reine Werksprototypen sein, oder? Überall deutlich als solche
> gekennzeichnet - da braucht man auch nichts groß zu veröffentlichen,
> jedenfalls nicht, so lange noch "vorab getestet" wird, und wie lange das ist,
> bestimmten nur die Beteiligten.
>
>
> > Aber um das auch zu betonen: Ich will euch nicht davon abhalten, aber
> > ich will verhindern, daß ihr das einfach auf die leichte Schulter
> > nehmt.
>
> IMHO bist du hier einer der kompetentesten Teilnehmer, insofern vielen Dank
> für deinen Input, immer gern gesehen (wenn auch nicht immer komplett einer
> Meinung)! (so, das musste auch mal gesagt werden ;-) )
>
> Gruß Nino

--
Informationen zum Abmelden: E-Mail an discuss+help@de.libreoffice.org
Probleme? http://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: http://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: http://listarchives.libreoffice.org/de/discuss/
Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert