Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.