Re: [de-users] Re: LO 3.6 Writer: Rahmen nicht mehr zu bearbeiten

Hi Ulrich, *,

2012/11/5 Ulrich K. <ulrichkarim@gmail.com>:
> Robert Großkopf <robert <at> familiegrosskopf.de> writes:
> > der Fehler ist bekannt und auch gemeldet:
> > https://bugs.freedesktop.org/show_bug.cgi?id=55842

Der Bug ist nicht in der liste der "Most annoying bugs" (einem
Meta-issue) gelistet und so nicht im direkten Fokus der Entwickler.

> Leider sieht es nicht so aus.
> Im Bugreport schreibt jemand, dass der Fehler in LibO-Dev 3.7.0.0.alpha0+
> noch da ist.
>
> Das verstehe ich nicht, Christian L. sagte doch, dass gemeldete und
> nachvollziehbare Fehler in der nächsten Version,
> also 4 Wochen später behoben werden.

Das hat ja Stefan schon klargestellt...
Gibt mehr Bugs/Feature wünsche als dass von den Entwicklern umgesetzt
werden können, deshalb ist es wichtig, dass ihnen zugearbeitet wird,
dass die wirklich wichtigen Bugs in den most-annoying-bugs zu den
jeweiligen Releasen landen.

Schlüssel dazu ist die Bug-Triage
http://wiki.documentfoundation.org/QA/BugTriage
enthält alle nötigen Infos.

Je besser ein Issue geschrieben/aufbereitet ist, desto größer die
Bereitschaft sich damit zu befassen. Wenn man erst 15 Minutern
rumrätseln muss, was eigentlich Sache ist, dann geht man lieber weiter
zum nächsten.
Ebenso schaut man sich die als release-kritisch eingestuften Bugs vor
den sonstigen an.

Sprich: Wenn man wirklich will, dass ein Bug in der nächsten Version
gefixed wird, dann braucht es Eigeninitiative. Dann muss man sich
darum kümmern, dass der Bug entsprechend eskaliert wird. Entweder
indem man seine "Beziehungen" spielen läßt (andere dazu nötigt die
Arbeit zu tun) oder die nötigen Schritte selbst erledigt. Ist einem
die eigene Zeit dafür zu schade, dann braucht man sich auch nicht
nachträglich darüber beschweren, dass nichts passiert ist.

Aber auch wenn ein bug in den most-annoying-bugs landet ist das noch
keine Garantie dafür, dass er bis zum nächsten Release gefixed wird -
das hängt dann von der Komplexität des Problems ab, und ggf.
Seiteneffekten eines möglichen Fixes.
Diese Seiteneffekte und sonstige Risiken lassen sich am besten
vermeiden, wenn man den Bug zeitnah zu seiner "einführung" meldet.
Sprich: Je früher der Bug gemeldet wird (mit der entsprechenen
Information), desto höher die Chance eines Fixes.
Im einfachsten ist z.B. einfach ein Rückgängigmachen des Commits, das
das Fehlferhalten auftreten lässt. Das geht natürlich nur, wenn man
eine entsprechende Codeänderung auch ausfindig machen kann → sprich je
weniger Änderungen in Frage kommen, desto einfacher. Und auch wenn man
die Änderung nicht komplett rückgängig macht, so hat man dann schon
das Wissen, welcher Code dafür verantwortlich ist und muss nicht erst
groß debuggen.

tl;dr:

* Bugs früh reporten (→ Interessierte (Dienstleister, QA-Freiwillige,
tapfere Nutzer) sollten immer mal wieder die daily-builds testen und
schauen, ob die für sie selbst kritischen Funktionen so funktionieren
wie erwartet)
* die reporteten Bugs kategorisieren, vorsortieren/aufarbeiten. Je
weniger Zeit mit anderen Bugs vertrödelt wird, desto mehr Zeit bleibt
für die "wichtigen".
* die wichtigen Bugs entsprechend eskalieren, wenn ein Bug nicht in
dem entsprechenden most-annoying-bug gelistet ist, dann ist er nicht
im Fokus.

Ja, das kostet Zeit und geht nicht automatisch. Aber wie schon
geschrieben: Wenn es die eigene Zeit nicht wert ist, dann erst recht
nicht die Zeit der Entwickler.

ciao
Christian

-- 
Informationen zum Abmelden: E-Mail an users+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/users/
Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert