Prioritäten für Bugs und Fehler

From Joomla! Documentation

Revision as of 10:07, 26 August 2021 by Max123kl (talk | contribs)
Other languages:
Bahasa Indonesia • ‎Deutsch • ‎English • ‎Nederlands • ‎català • ‎español • ‎français • ‎русский • ‎हिन्दी

Um die Prioritätensetzung für Fehlerberichte und Bugs zu verdeutlichen, ist hier ein oft vorkommendes Szenario angeführt.

Man versucht seit Stunden, ein Problem zu lösen, im Forum konnte niemand helfen, in der Dokumentation ist dazu nichts zu finden und die verfügbare Zeit wird knapp. Teit, das Prolem im Tracker einzureichen. Nach all dem Aufwand ist es ein kritisches Problem. Deswegen wählt man auch "Priorität: Kritisch".

Was passiert? Jemand vom "Joomla! Bug Squad" (JBS) ändert die Priorirär auf Medium. Warum? Ist der Bericht unwichtig und wird er nicht behandelt? Sind sie gemein und gefühllos? Natürlich nicht. Es zeigt nur, dass die Entwicklungs-Arbeitsgruppe strikte Definitionen der Prioritäten hat.

Definition der Prioritäten

Fehlerberichte (Bugs) werden nach dieser Charakteristik eingestuft:

Priorität 1 → Kritisch

Der Trunk arbeitet nicht. Wichtige Teile sind unterbrochen, Schlüsseloperationen nicht möglich. Beispiele sind Anmeldung, Installation, Erweiterungs-Installation, Javascript-Fehler, die "Sichern" und Ähnliches verhindern, etc. Ebenso Fatal-PHP-Fehler.

Priorität 2 → Dringend

Teile des Codes verhindern Operationen in ernsthafter Weise oder verursachen Schäden an angekündigten Funktionen.

Priorität 3 → Medium

Fehler verhindern angekündigte Funktionen, die Applikation aber arbeitet. Beispiele sind nicht wie angekündigt arbeitende Parameter, Sprachdateien, die nicht wie erwartet geladen werden, etc.

Priorität 4 → Niedrig

Geringer Verlust an Funktion und generell lästiges Verhalten. Beinhaltet weniger bekannte Plattform- oder Browserspezifische Probleme, die in der jeweiligen Umgebung eine Mehrheit betreffen, insgesamt aber eine Minderheit sind. Betrifft auch fehlende Übersetzungsstrings.

Priorität 5 → Sehr Niedrig

Kosmetische Probleme, falsch geschriebene Wörter, graphisch unausgerichtete Objekte, wenig bekannte Fehler mit Parametern, etc.

Was bedeutet das?

Zuerst: Üblicherweise sieht man kein "Priorität 1"-Problem oder muß es berichten. Ausgenommen die ersten Tage nach einer Joomla!-Veröffentlichung, einem Sicherheitsproblem, man verwendet eine Unterversion oder ein Nightly Build. Denn ist ein "Priorität 1"-Problem in der Codebasis, gibt es keine Joomla!-Veröffentlichung. Dasselbe gilt für "Priorität 2" (Dringend). Ein wirkliches "Priorität 1"-Problem beeinflusst eine neue Veröffentlichung. Ein "Priorität 1"- oder "Priorität 2"-Problem in der Codebasis verhindert geplante Veröffentlichungen. Eine ernsthafte Sache, da eine Veröffentlichung Bugfixes und Verbesserungen enthält, die der Community damit vorenthalten wird. Das Betreiben einer ungeplanter Veröffentlichung ist ebenfalls schwerwiegend, weil Arbeiten in anderen Bereichen gestoppt werden und sich alle Bemühen auf die Veröffentlichung richten.

Einzige Ausnahme ist das Berichten einer Sicherheitslücke, aber der Tracker ist nicht der Platz, eine Sicherheitslücke zu berichten.

Das bedeutet nicht, dass es keine "Priorität 1"- oder "Priorität 2"-Problem gibt. Ein Beispiele eines "Priorität 1"-Problems ist Read More link does not appear on Category Blog Layout.

Bevor man sein Problem als Priorität 1 oder 2 markiert, sollte man alle erwähnten Informationen bedenken.

Die meisten Berichte haben Priorität 3, Medium. Allerdings sind manche als Priorität 4 oder 5 markiert, sie werden aber genauso behoben. Ist es ein einfacher Fix, sogar mit einem Patch oder Codevorschlag, kann er sofort verwendet werden. Einige JBS-Mitglieder sind auf Sprachdateien, CSS oder andere Themen spezialisiert, die oft Stufe 4 oder 5 haben. Berichte müssen nicht Stufe 3 haben, um Aufmerksamkeit zu bekommen.