QA/Fehler Sichtung

    From The Document Foundation Wiki
    < QA
    This page is a translated version of the page QA/BugTriage and the translation is 100% complete.

    TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Spende

    Other languages:


    Einführung

    Diese Seite bietet Informationen über die Sichtung der Fehler von LibreOffice. Sichtung ist der Name für, Bestätigung, Priorisierung und Organisation der Fehlerberichte und ist ein guter Platz für neue Mitwirkende und Mitwirkende mit begrenzten Programmiermöglichkeiten um mitzuhelfen, dass LibreOffice ein besseres Produkt für jeden wird. Sichtung ist ein unglaublich wichtiger Aspekt der Entwicklung, der sowohl Nutzer als auch Entwicklern nützt.

    Wo andere QA-Mitglieder zu finden sind

    Es gibt einige Stellen, an denen Mitglieder des QA-Teams zu finden /kontaktieren sind, viele davon können bei Fraugen zur Sichtung helfen und sichten aktiv selbst.

    1. Mailing Listen
      • libreoffice-qa@lists.freedesktop.org
      • libreoffice@lists.freedesktop.org
    2. IRC Channels auf Libera Chat
    3. QA-Mitglieder
      Hier ist eine Liste der QA-Mitglieder (Füge gerne Deinen eigenen Namen hinzu, wenn Du beabsichtigst, bei der QA mitzumachen). Wenn der Nutzer sein Enverständnis gegeben hat, ihn direkt zu kontaktieren, dann mach das so. Außerdem hängen sie manchmal im Chat Room ab.

    Gemeldete Bugs abarbeiten

    Dieser Abschnitt listet die notwendigen Schritte zur anständigen Sichtung auf. Dieses Handbuch will kurz und prägnant sein. Links in einigen Abschnitten bieten mehr Informationen zum jeweiligen Schritt. Die Sichtung kann generell in drei Teile aufgeteilt werden. Die "Vorbereitung", die "Reproduktion" und die "Priorisierung".

    Zusammenfassung der Schritte

    1. Finde Fehler zur Sichtung
    2. Vorabauswahl der Fehlerberichte
    3. Suche nach Dubletten des/des Fehler.
    4. Prüfe die angegebenen Informationen im Fehlerbericht.
    5. Versuch der Fehlerreproduktion
    6. Fehler Status setzen
    7. Regressionstest
    8. Fehler priorisieren

    Einzelheiten zu den einzelnen Schritten

    Vorbereitung

    Im Allgemeinen bieten sich die folgenden Schritte in der Vorbereitung der Fehlersichtung an. An den Fehlern kann nur eingeloggt gearbeitet werden (bitte melde Dich an, wenn noch nicht geschehen). Und sobald Du Dich angemeldet hast, wäre es gut, wenn Du in den Einstellungen unter 'Automatically add me to the CC list of bugs I change' angibst, 'Only if I have no role on them', wenn Du benachrichtigt werden willst, wenn jemand auf Deine Kommentare antwortet.

    Schritt 1: Finde Fehler zur Sichtung

    a) Bugzilla Suche

    Gehe zu LibreOffices Bug Tracker System unter bugs.documentfoundation.org. Nach der Anmeldung blättere offene Ausgaben nach Komponenten durch oder suche allgemein nach Fehlern, die:

    a) für LibreOffice angegeben sind,

    b) den Status UNCONFIRMED oder REOPENED haben,

    c) jedes andere Kriterium erfüllen, nach dem Du suchen willst.

    Da Du schon einmal da bist, suche nach einem Fehler, den Du sichten willst. Eine übliche Suche nach Fehlern nutzt das erweiterte Suchformular oder die Eingabe der Suchkriterien in das Quick Search Feld (Bugzilla Quick Search Hilfe). Du kannst auch die folgenden direkten Links zur Suche nutzen. Klicken auf den Link führt zu Bugzilla Ergebnisseite:

    Schritt 2: Vorabauswahl der Fehlerberichte

    Einige Fehler brauchen die besondere Aufmerksamkeit durch spezielle Teams:

    UX Erweiterungen

    Alle Fehler, die eine Erweiterung des UI/UX von LibreOffice betreffen, müssen an das UX-Team weitergeleitet werden.

    1. Ergänze das Schlüsselwort 'needsUXEval'.
    2. Ergänze dies in der CC-Liste: libreoffice-ux-advise@lists.freedesktop.org.
    3. Aktualisiere den Status.
      • Wenn die Anforderung komplett und plausibel erscheint, Status -> NEW.
      • Wenn die Anforderung unvollständig erscheint oder Erklärungen erfordert, Status -> NEEDINFO.
      • Hinterlasse einen Kommentar analog zu:
    UX Team -- please take a look at this enhancement. Thanks!

    Einige Fehler haben im Bugzilla nichts verloren. Für eine Liste der Punkte, die woanders hin gehören, siehe die Fehlerbericht Seite.

    • Wenn einer dieser Fehler im Bugzilla erscheint, ändere den Status bitte auf RESOLVED NOTOURBUG und ergänze folgenden Kommentar:
    Danke, dass Sie mit uns in Kontakt treten!
Obwohl sich Bugzilla manchmal im Zentrum des Universums fühlt, gibt es einige Punkte, die woanders gemeldet werden sollten. Die richtige Stelle für Ihr Problem finden Sie bitte unter https://wiki.documentfoundation.org/QA/BugReport/de#Nicht_alle_Bugs_gehen_an_Bugzilla.

    Schritt 3: Suche nach Dubletten

    Dubletten sind Berichte, die dehr ähnlich oder identisch sind, aber von verschiedenen Nutzern verfasst sind. Typischerweise wird der NEW Status beibehalten, der die brauchbarsten Informationen zur Verfügung stellt und die anderen werden als RESOLVED DUPLICATE geschlossen. Obwohl also ein älterer Bericht existiert, braucht dieser nicht aktiv gehalten werden, wenn er verwirrende oder unvollständige Informationen enthält. Geschlossene Dubletten werden automatisch von Bigzilla gezählt und sind unter Most Frequently Reported Bugs verfügbar. Um festzustellen, ob es Dubletten für den gerade bearbeiteten Bericht gibt, verwende eine schnelle Suche durch die Berichte im Bugzilla. Du brauchst keine Ewigkeit darauf zu verwenden. Wenn Du mehr Berichte gesichtet hast, wirst Du immer mehr Dubletten erkennen, ohne die Suche bemühen zu müssen.

    Wenn Du eine Dublette findest, mach weiter mit Schritt 5.

    Schritt 4: Überprüfe Informationen

    Informationen zu überprüfen, ist entscheidend für die Entwicklung. Auf folgendes solltest Du dabei achten:

    1. klare und informative Zusammenfassung
    2. klare Problembeschreibung
    3. Schritte zur Reproduktion des Fehlers -- wenn diese nicht bereits aus der Zusammenfassung und/oder Beschreibung hervorgehen
    4. Anhänge -- in vielen Fällen werden Anhänge zur Reproduktion des Fehlers nötig, fehlende Anhänge können die korrekte Fehlerbehebung verhindern.
    5. Wenn sich der Bericht auf externe Daten bezieht (Screenshots, Dokumente, Bildschirmvideos usw.), kopiere sie und füge sie bitte dem Fehler bei. Damit verschwinden sie später nicht und machen den Fehler bleibt damit nachvollziehbar.

    Wenn alle Informationen nicht hier beisammen sind, mach weiter mit Schritt 5.

    Schritt 5: Versuch der Reproduktion

    Wenn der Fehler die Vorbereitung "passiert" hat, ist es Zeit, den Fehler nachzuvollziehen.

    Mache folgendes: Gehe die nötigen Schritte durch und versuche den Fehler nachzuvollziehen, das ist einfach! Wenn Du ihn nachvollziehst, denke an diese Dinge:

    1. Hat der Melder des Fehlers selbst genug Informationen in Bugzilla hinterlassen, oder hast Du extra Schritte benötigt? Wenn extra Schritte nötig waren, hinterlasse diese in einem Kommentar.
    2. Führte Deine Reproduktion zum selben Ergebnis, etwas ähnlichem aber nicht demselben oder funktionierte alles problemlos?

    Schritt 6: Status setzen

    Dieser Abschnitt ist die letzte "Pflichtübung" einer erfolgreichen Sichtung und kann nur gemacht werden, wenn die Schritte 1 - 4 vollzogen wurden (oder Schritt 3 und 4 nicht anwendbar sind).

    Der STATUS eines Fehlers ist abhängig von Deinen Ergebnissen der obigen Schritte. Im folgenden ist eine kurze Beschreibung der Verwendung jedes Statusses.

    1. NEW: Bestätigter Fehler, alle Informationen sind vorhanden.
    2. NEEDINFO: Nicht alle nötigen Informationen zur Reproduktion sind im Fehlerbericht vorhanden. Bitte frage eine bestimmte Person nach einer bestimmten Information in einem Kommentar.
    3. RESOLVED: Diese Kategorie kommt mit mehreren Optionen. Z. Bsp., wenn der Fehler bereits berichtet wurde, wird er als RESOLVED DUPLICATE markiert. Oder wenn er wie beschrieben repliziert werden kann, aber bereits in einer früheren Version korrigiert wurde, ist RESOLVED WORKSFORME ein angemessener STATUS. Siehe RESOLVED für eine detaillierte Beschreibung aller möglichen Werte.
    4. VERIFIED: Diese Option ist nur verwendbar, wenn der aktuelle Fehlerstatus RESOLVED ist. Ein RESOLVED FIXED Fehler kann als VERIFED markiert werden, wenn Du bestätigen kannst, dass er in der im Fehlerbericht angegebenen Version beseitigt wurde. Es ist auch für den Entwickler hilfreich, der den Fehler verbessert hat und ist eine Bestätigung, dass das Problem nun gelöst ist. Andererseits kann der Melder selbst seinen eigenen Fehler mit dem Status RESOLVED WORKSFORME als VERIFIED WORKSFORME markieren, um zu überprüfen, dass er irgendwie berichtigt ist.
    5. INVALID: Es gibt viele Gründe, warum ein Fehler als ungültig kategorisiert wird. Jedenfalls benötigt das Input eines anderen QA-Mitgliedes. Wenn Du der Meinung bist, ein Fehler ist ungültig, forderst Du am besten eine zweite Meinung über den QA IRC channel an oder sendest eine eMail an die Mailing Liste mit dem Grund, warum Du ihn für ungültig hältst.
    6. UNCONFIRMED: Das ist der Status für alle neuen Fehler, die noch nicht durch die Sichtung gelaufen sind. So ein Fehler kann auch im Status NEEDINFO sein.

    JEDES Mal, wenn Du etwas änderst, gib einen Kommentar, der freundlich erklärt, warum Du die Änderung gemacht hast.

    Die folgenden Diagramme sind Beispiele dafür, wie ein STATUS visuell dargestellt werden kann. Wenn Du willst, kannst Du Deine eigene Version erstellen und hochladen.
    PDF Datei
    LibreOffice Draw Datei

    Schritt 7: Regressionstest

    Verwende ältere Versionen von LibreOffice, um herauszufinden, ob der Fehler von Anfang an schon auftritt.

    Lade einige Versionen herunter und installiere sie, die älteste sollte LibreOffice 3.3 sein. Du solltest mindestens eine Version aller Hauptversionen haben (3.x, 4.x, 5.x, 6.x...).

    Beachte bitte, dass einige Funktionen erst im Laufe der Zeit eingeführt wurden, um irrelevante Ergebnisse zu vermeiden. Bite frage auch andere Teammitglieder, wenn Du unsicher bist.

    • Wenn der Fehler bereits in Version 3.3.0 auftritt, setze die Version auf "übernommen aus OOo" und ergänze den folgenden Kommentar:
    Dieser Fehler ist bereits in LibreOffice 3.3.0 vorhanden.

    Ändere die Version auf "übernommen aus OOo".
    • Wenn der Fehler in Version 3.3.0 noch nicht auftritt, ergänze "regression" in das Schlüsselfeld und ergänze folgenden Kommentar:
    Dieser Fehler ist in LibreOffice 3.3.0 noch nicht vorhanden, daher ist es eine Verschlimmerung.

    Für Verschlimmerungen vor Version 3.5.0 ergänze außerdem das Schlüsselwort preBibisect. Für neuere Verschlimmerungen ergänze das Schlüsselwort bibisectRequest und aktualisiere die Version auf die erste bekannte problematische Version.

    Schritt 8: Fehler priorisieren

    Wir heben aktuell nur kritische Fehler dadurch hervor indem wir Entwickler auf CC setzen und Schlüsselwörter ergänzen. Siehe auch weiter unten für mehr Informationen

    Die Priorisierung eines Fehlers ist ziemlich subjektiv, aber der Sichter sollte immer versuchen, in der Priorisierung konsistent zu bleiben. Die QA Mitglieder für die Sichtung sollten eine klare Vorstellung haben, was jeder Priorisierungsstatus bedeutet und dann mit dieser Methode vorgehen. Auch sollten Kommentare im Fehler nach der Priorisierung für den Berichter (und für Entwickler und andere Nutzer) hilfreich sein bei der Erklärung, wie genau diese Priorität zustande kommt.

    Um Fehler höher als Medium-normal einzustufen, muß man der Gruppe der Bugzilla-Teilnehmer zugeordnet sein. Um dort zugeordnet zu werden, kontaktiere bitte einen der Bugzilla Admins.

    Das folgende Diagramm zeigt ungefähre Richtlinien, wie Priorisierungen behandelt werden.

    Beispiel 1 JPG

    Beispiel 1 Draw

    Es ist üblicherweise einfacher, die Dringlichkeit eines Fehlers zu bestimmen, als sich Gedanken über ein brauchbares Prioritätensystem zu machen.

    Kleine optische Zwicker im UI können als niedrige Priorität und trivial eingestuft werden.

    Probleme, die Dich ärgern, die Du aber tolerieren oder irgendwie umgehen kannst, können als minor eingestuft werden.

    Fehler, die Funktionalität verhindern und nicht umgangen werden können, sind normal.

    Abbrüche, Hänger oder Einfrieren, die aus einer bestimmten Datei oder Kommando resultieren, sind major.

    weitere nützliche (optionale) Schritte

    Schlüsselwörter

    Das Feld Keywords enthält Schlüsselwörter, die die Kategorisierung des Fehlers betreffen.

    Ein paar Kategorien für Schlüsselwörter sind:

    Ein interessantes Schlüsselwort ist needsDevEval. Ein easyHack ist ein Fehler, der sehr wahrscheinlich schnell beseitigt ist und von einem neuen Entwickler und/oder einem Entwickler ohne große Programmiererfahrung erledigt werden kann. Als QA sollten wir einen Fehler NICHT als easyHack markieren, der mehrere Schritte benötigt (inklusive einen Entwickler als Mentor für den Fehler suchen) beinhaltet. Wenn Du denkst, ein Fehler qualifiziert sich als easyhack, markiere ihn als needsDevEval.

    Absturzberichte

    Mit einem Absturzbericht (auch "backtrace" genannt) für einen Fehler ist es für einen Entwickler einfach die Fehlerursache zu identifizieren. Wenn ein Absturzbericht dem Fehlerbericht beigefügt wird, wird das Schlüsselwort havebacktrace im Feld Keywords ergänzt.

    Metaberichte

    Siehe auch existing meta reports, dort werden Berichte der selben Art gesammelt. Wenn Du etwas passendes findest, ergänze die Metabericht Nummer im Blocks Feld des Berichtes, den Du gerade sichtest.

    Kommentare

    Kommentare agieren als Notiz, die jedem einen Überblick auf die Kommentargeschichte und die Relevanz individueller Kommentare verschaffen. Klicke auf den Text im Titel des Kommentares, gib Deinen Kommentar dazu und speichere den Bericht. Du kannst neue Kommentare einführen oder existierende Kommentare verwenden. Der Kommentar muss nicht extra gespeichert werden. Das Kommentar-Formular unterstützt Autovervollständigung.

    Die Eingabe eines dieser Kommentare versteckt den Kommentar standardmäßig: obsolete, spam, me-too, off-topic, abusive, no-value, bibisection, noise. Ein versteckter Kommentar kann durch die Funktion "Kommentaranzeige umschalten" im Kommentarkopf angezeigt werden. Ein normaler Kommentar kann auch versteckt werden und ein markierter Kommentar kann agezeigt werden, indem der Kommentarname in der Liste der "Kommentare" neben der Fehlerbeschreibung angeklickt wird (Kommentar 0). Klicke auf "Expand all comments" um alles anzuzeigen.

    Bearbeitung weiterer Informationen

    Ein Sichter überprüft die Informationen, die in einem Fehlerbericht ursprünglich vom Berichterstatter angegeben wurden. Folgende Dinge sind zu überprüfen:

    • Produkt
    • Version
    • Betriebssystem

    Entwickler auf CC setzen

    Dieser Punkt sollte nur gemacht werden, wenn Du sicher bist, dass der Fehler wichtig genug ist, dass der Entwickler auf CC gesetzt wird. Wenn Du meinst, der Fehler ist ernst genug, um erhöhte Aufmerksamkeit zu verdienen, aber trotzdem nicht in die Kategorie lästigste Fehler fällt, dann frage bitte einen Experten um Rat. Bitte frage auch mit Bedacht, da wir unsere Experten nicht mit unwichtigen Fehleranfragen zumüllen wollen. Um einen User hinzuzufügen, ergänze einfach seinen Namen auf die CC-Liste und schreibe einen Kommentar dazu, warum Du ihn auf CC gesetzt hast. Die richtigen Namen können auf alle Fälle in der Expertenliste gefunden werden.

    QA der CC-Liste hinzufügen

    Meistens wird das nicht genutzt. Aber wenn Du Dich oder ein anderes Mitglied auf die Liste setzen willst, dann mach es. Nochmal, bitte setze einen Kommentar, wenn Du jemand anderes auf die Liste setzt, damit er weiß, was vor sich geht.

    Kompatibilitätstest

    Wenn zu Testzwecken eine Datei mit Microsoft Office geöffnet oder gespeichert werden muss, und kein Zugang zu dieser Software vorhanden ist, dann kann vom Office Web Viewer Gebrauch gemacht werden. Dieser funktioniert mit Word, Excel, PowerPoint oder ODF Dokumenten. Man lädt das Dokument irgendwo hoch und verwendet den URL an das Ende dieses Links:

    https://view.officeapps.live.com/op/view.aspx?src=

    Über den Print Button im Menü ganz oben und danach über Open PDF erhält man ein PDF des Dokuments. Dadurch sieht man, wie das Dokument in der aktuellen Version aussieht und man kann das PDF für Bugzilla verwenden.

    Bugzilla Anhänge arbeiten mit dem Viewer.

    die geeignete Nutzung des live viewers in Firefox
    • Füge ein neues Lesezeichen hinzu,
    • Gib einen Namen an,
    • Setze den URL auf:
    https://view.officeapps.live.com/op/view.aspx?src=%s
    • Gib ein Keyword wie lv an und bestätige mit OK:
    • Jetzt kann das Lesezeichen-keyword mit einem Fehlerdokument-URL in der Adresszeile verwendet werden, um das Fehlerdokument im Office Live Viewer zu öffnen:
    lv https://bugs.documentfoundation.org/attachment.cgi?id=180059

    Spezielle Sichtungshinweise für das QA Team

    Hier sind einige Hinweise für Fortgeschrittene Sichter im QA/Team. Wenn Du neu bist, dann ignoriere diese einfach!

    schwierig einzuordnende / zu schliessende Fehlerberichte

    Manchmal benötigen wir besondere Software oder Hardware um einen Fehler zu reproduzieren oder wir sehen uns vor anderen Schwierigkeiten bei der Aufklärung. Für diese Fälle haben wir:

    Erweiterung

    Am besten holt man den Ersteller der Erweiterung in den Sichtungsprozess. Die Verantwortung zur Kontaktierung des Erstellers liegt beim Fehlerberichter.

    Siehe auch:

    Gebietsschemarelevante Probleme

    Manchmal sehen wir uns mit Problemen in Gebietsschematas konfrontiert. Es kann Situationen geben, bei denen sich ein nationaler Standard von der internationalen Praxis unterscheidet. In diesen Fällen kann es hilfreich sein, den Berichterstatter an Unicode und sein survey tool weiterzuleiten.

    Empfohlene Sichtungs Folge

    Die folgende Tabelle zeigt eine vorgeschlagene Reihenfolge der Sichtung. Das Ziel der QA ist es, die schlimmsten Fehler zuerst zu bestätigen.

    Tabelle nach Betriebssystem

    Beschreibung Alle Fehler Windows Linux macOS Kommentare
    Abbruch Fehler CrasherAll CrasherWindows CrasherLinux CrashermacOS Dies sind die Fehler, die "crash" oder ein ähnliches Wort im Titel haben. Für Abbrüche wird die Schwere auf Major/Essentiell gesetzt, je nach dem wie viele Nutzer betroffen sind. QA sollte auch überprüfen, ob es sich um eine Verschlimmerung handelt und ggf. "regression" den Schlüsselwörtern hinzufügen.
    mögliche Verschlimmerungen possibleRegressionAll possibleRegresionWindows possibleRegressionLinux possibleRegressionmacOS Wenn der Fehler als Verschlimmerung bestätigt ist, wird das Schlüsselwort "possibleRegression" entfernt und "regression" ergänzt.
    Schlüsselwort "Regression" (Verschlimmerung) RegressionAll RegressionWindows RegressionLinux RegressionmacOS Der Melder des Fehlers oder jemand anders hat "regression" als Schlüsselwort ergänzt. Genauso wichtig wie die obige Zeile, aber da Bugzilla keine "oder"-Suche zulässt, brauchen wir hier zwei Zeilen.
    essentielle ("Critical") Fehler CriticalAll CriticalWindows CriticalLinux CriticalmacOS Nur Mitarbeiter mit speziellen Privilegien können Fehler als essentiell einstufen. Essentiell ist für sehr schwere Fehler (wie ein Datenverlust, der viele Nutzer betrifft). Zur Einschätzung siehe das Prioritätendiagramm.
    Schwere ("Major") Fehler MajorAll MajorWindows MajorLinux MajormacOS Nur Mitarbeiter mit speziellen Privilegien können Fehler als essentiell einstufen. Essentiell ist für sehr schwere Fehler (wie ein Datenverlust, der viele Nutzer betrifft). Zur Einschätzung siehe das Prioritätendiagramm.
    Alle Fehler AllBugs AllWindows AllLinux AllmacOS Liste aller Fehlerberichte (ohne die Erweiterungen). Wenn die obersten Fehler zuerst abgearbeitet werden, dann bleiben dijenigen mit leicht geringerer Priorität übrig. Unser Vorschlag ist, diese in chronologischer Reihenfolge abzuarbeiten. (die ältesten zuerst, sodass die Fehler Priorität erhalten, die am Ältesten sind).
    Erweiterungsanforderungen EnhancementAll EnhancementWindows EnhancementLinux EnhancementmacOS Erweiterungsanforderungen haben die geringste Priorität als gültige Anforderung bestätigt zu werden.

    Tabelle nach Komponente

    Beschreibung Writer Calc Impress Draw Base Andere Kommentar
    Abbruchfehler WriterCrasher SpreadsheetCrasher PresentationCrasher DrawingCrasher DatabaseCrasher OtherCrashers 'Critical' ist nur für die schlimmsten Fehler reserviert (z. Bsp. solche, die LibreOffice nicht installierbar machen). Zur Einschätzung siehe das Prioritätendiagramm.
    mögliche Verschlimmerung WriterPosReg SpreadsheetPosReg PresentationPosReg DrawingPosReg DatabasePosReg OtherPosReg Wenn der Fehler als Verschlimmerung bestätigt ist, wird das Schlüsselwort "possibleRegression" entfernt und "regression" ergänzt.
    Schlüsselwort "Regression" (Verschlimmerung) WriterRegression SpreadsheetRegression PresentationRegression DrawingRegression DatabaseRegression OtherRegressions Der Melder des Fehlers oder jemand anders hat "regression" als Schlüsselwort ergänzt. Genauso wichtig wie die obige Zeile, aber da Bugzilla keine "oder"-Suche zulässt, brauchen wir hier zwei Zeilen.
    essentielle ("Critical") Fehler WriterCritical SpreadsheetCritical PresentationCritical DrawingCritical DatabaseCritical OtherCritical Nur Mitarbeiter mit speziellen Privilegien können Fehler als essentiell einstufen. Essentiell ist für sehr schwere Fehler (wie ein Datenverlust, der viele Nutzer betrifft). Zur Einschätzung siehe das Prioritätendiagramm.
    Schwere ("Major") Fehler WriterMajor SpreadsheetMajor PresentationMajor DrawingMajor DatabaseMajor OtherMajor Nur Mitarbeiter mit speziellen Privilegien können Fehler als schwer einstufen. Schwer ist für sehr schwere Fehler (wie ein Datenverlust), die aber nur wenige Nutzer betrifft oder nur in vereinzelten Fällen mit individuellen Dokumenten auftritt. Zur Einschätzung siehe das Prioritätendiagramm.
    alle anderen Fehler WriterOther SpreadsheetOther PresentationOther DrawingOther DatabaseOther AllOther Das sind alle anderen Fehler, die als weniger als "schwer" markiert sind und ohne die Erweiterungen.
    Erweiterungsanforderungen WriterEnhance SpreadsheetEnhance PresentationEnhance DrawingEnhance DatabaseEnhance OtherEnhance Erweiterungsanforderungen
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=QA/BugTriage/de&oldid=767909"