QA/BugTriage

TDF LibreOffice Document Liberation Project Blogs gemeenschap Weblate Nextcloud Redmine Ask LibreOffice Doneren

• Hoofdpagina
• Ontwikkeling
• Ontwerp
• QA
• Evenementen
• Documentatie
• Website
• Localisatie
• Toegankelijkheid
• Marketing
• Diversiteit
• Help

• Bug Report
• Bug Triage
• Projects
• Regression Test
• Automated Tests
• Bibisect
• QA Meetings
• QA FAQs

Introductie

Informatie over het uitvoeren van triage voor bugs in LibreOffice. Met triage bedoelen wij het het bevestigen van de fout, het bepalen van de prioriteit bij het oplossen, het werken met bugrapporten en het inwerken van nieuwe medewerkenden met beperkte mogelijkheden om te zorgen dat LibreOffice een goed product blijft en een beter product wordt. Het is een belangrijk onderdeel bij de ontwikkeling wat zowel voor de ontwikkelaars als de gebruikers voordelen biedt.

Andere QA-leden vinden

U kunt op meerdere manieren met leden van het QA-team in contact komen, de meesten kunnen u helpen met vragen over triage.

1. Mailinglijsten
   • libreoffice-qa@lists.freedesktop.org
   • libreoffice@lists.freedesktop.org
2. IRC op Libera Chat
   • #libreoffice-qa ^IRC://
   • #libreoffice-dev ^IRC://
3. QA Leden
   Dit is een lijst van QA-leden (voel u vrij om uzelf toe te voegen als u een bijdrage aan kwaliteitszorg hebt geleverd). Als de gebruiker toestaat dat u direct contact opneemt met de gebruiker, doe dat dan. Kijk ook of die gebruiker de chat gebruikt.
   • QA Ledenlijst

Stappen om bij een fout triage te doen

Hier geven we stappen aan om de triage goed te doen. We proberen dat bondig te doen, met links verwijzen we naar uitgebreidere in die stap relevante informatie. Het proces bestaat uit drie gedeelten. Eerst een "voorbereiding", dan een "reproductie" en tot slot het "bepalen van de prioriteit".

De stappen

1. Fouten zoeken
2. Filteren op foutrapporten
3. Zoeken naar dubbele fouten
4. Meegeleverde informatie in het foutrapport controleren
5. De fout proberen te krijgen, het reproduceren van de bug
6. De status zetten
7. Regressie testen
8. Prioriteit bepalen

Details van de stappen

Voorbereiden

In het het algemeen zult u de volgende stappen willen doen als voorbereiding voor de triage. U dient dient ingelogd te zijn om aan de bugs te werken (als u nog geen account heeft, maak een account aan als u dat nog niet heeft). Stel in uw account in bij uw voorkeuren bij 'Automatically add me to the CC list of bugs I change' de waarde 'Only if I have no role on them' te kiezen, dan wordt u ingelicht als iemand op een bugrapport reageert, waar u ook een post heeft gedaan.

Stap 1: Fouten zoeken voor de triage

a) Bugzilla Search

Ga naar de LibreOffice bugtracker bugs.documentfoundation.org. Na het inloggen, bekijk de open issues per component of zoek naar een bug die:

a) betrekking heeft op een LibreOffice product

b) de status UNCONFIRMED of REOPENED heeft

c) u kunt uw keuze uitbreiden met eigen criteria om het aantal resultaten te beperken tot uw aandachtsgebied

Zoek daar naar een fout die u wilt beoordelen. Dat zoeken kan met de Geavanceerd zoeken of met het invoeren van zoektermen in het Snelle Zoekveld (Bugzilla Quick Search help). U kunt voor het zoeken ook de volgende links gebruiken. Na een klik op de link krijgt u in Bugzilla de pagina met de resultaten:

• Bugs reported in previous 2 weeks
• Bugs reported in previous 1 month
• All Bugs that Need Triage Work. (Beperkt tot 500 fouten, het laden van een grote lijst kan even duren, help ons dus door die lijst korter te maken!)
• All macOS Bugs that need confirmation

Step 2: Bugrapporten vooraf filteren

Bij enkele fouten is er aandacht nodig van een specifiek team:

UX Uitbreidingen

Alle rapporten over de uitbreidingen van de UI/UX van LibreOffice moeten worden gegeven aan het UX Team. Dit moet alleen worden gedaan op een punt waarop duidelijk is wat de melder wil. Laat de status liever staan als UNCONFIRMED. Gebruik alleen NEW, als u vindt dat de voorgestelde wijziging vanzelfsprekend moet worden doorgevoerd maar de vraag is hoe dat moet gebeuren.

1. Voeg het keyword 'needsUXEval' toe
2. Zet bij de CC: libreoffice-ux-adviselists.freedesktop.org
3. Voeg commentaar toe als:

UX Team -- please take a look at this enhancement. Thanks!

Sommige bugs horen helemaal niet thuis in Bugzilla. Voor een lijst met onderwerpen die elders thuishoren, zie de BugReport pagina.

• Als een van deze bugs is ingediend in Bugzilla, wijzig dan de Status in RESOLVED NOTOURBUG en voeg het volgende toe als een opmerking:

Thank you for getting in touch with us!
Although Bugzilla sometimes feels like the center of the
Universe, there are a few topics that need to be
reported elsewhere. To find the right place to report
your issue, please look at the BugReport wiki page:
https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla

Stap 3: Zoeken naar dubbelen

Duplicaten zijn rapporten die erg op elkaar lijken of identiek zijn, maar door verschillende gebruikers worden gerapporteerd. U wilt meestal de status NEW voor het rapport met de meest waardevolle informatie behouden en andere als RESOLVED DUPLICATE sluiten. Dus ook al bestaat er een ouder rapport, het is niet nodig om het open te houden, als het verwarrende of onvolledige informatie bevat. Gesloten duplicaten worden automatisch geteld door Bugzilla en zijn beschikbaar op de pagina meest gemelde bugs. Wanneer u triage doet, controleer dan die lijst en doorzoek snel de rapporten in Bugzilla om te zien of er duplicaten zijn van het rapport dat u onderzoekt. U hoeft hier niet veel tijd aan te besteden. Naarmate u meer rapporten ziet, kunt u duplicaten gaan herkennen zonder dat u de zoekopdracht hoeft te gebruiken.

Als u een dubbele bug vindt, ga dan naar stap #5

Stap 4: Informatie controleren

Het controleren van informatie is van cruciaal belang voor ontwikkeling. Waar u op moet letten, is het volgende:

1. Duidelijke en zinvolle samenvatting
2. Duidelijke probleembeschrijving
3. Stappen om het probleem te reproduceren - indien niet duidelijk uit samenvatting en / of beschrijving
4. Bijlagen - in veel gevallen zijn bijlagen nodig om het probleem te reproduceren, als bijlage (en) niet worden verstrekt, kan dit de juiste oplossingen belemmeren
5. Als het rapport verwijst naar externe gegevens (schermafdrukken, documenten, screencasts, enz.), Kopieer en voeg ze toe aan de bug, zodat ze later niet verdwijnen en uiteindelijk niet-reproduceerbaar worden.

Als niet alle informatie goed is, ga dan verder met stap #5

Stap 5: De fout proberen te reproduceren

Als de bug de voorbereidingsstappen heeft "doorstaan", is het tijd om te proberen de bug te reproduceren.

Doe precies dat: doorloop de stappen die nodig zijn en probeer de bug te reproduceren, zo eenvoudig! Wanneer u het reproduceert, moet u rekening houden met het volgende:

1. Heeft de bug reporter genoeg informatie achtergelaten in Bugzilla zelf om de bug te reproduceren, of moest u extra stappen ondernemen? Als er extra stappen nodig waren, voeg dan een opmerking toe om de extra stap(pen) te beschrijven.
2. Heeft de reproductie tot hetzelfde resultaat geleid, iets vergelijkbaars maar niet identiek, of werkte alles vlekkeloos?

Stap 6: Status zetten

Dit gedeelte is de laatste "verplichte" stap van een succesvolle triage en kan alleen worden uitgevoerd als de stappen #1 tot #4 zijn voltooid (of #3 als #4 niet van toepassing is).

De STATUS van de bug is afhankelijk van uw resultaten van de bovenstaande stappen. Hieronder vindt u een korte beschrijving van elke status.

1. NEW: Bevestigde bug, alle benodigde informatie is aanwezig
2. NEEDINFO: Alle informatie die nodig is om replicatie te proberen, is niet opgenomen in het bugrapport. Vraag een bepaalde persoon om een bepaalde informatie te verstrekken.
3. RESOLVED: Deze categorie wordt geleverd met verschillende opties. Als het probleem bijvoorbeeld al is gemeld, kunt u het markeren als RESOLVED DUPLICATE. Of als u de bug kunt repliceren zoals beschreven, maar het is al opgelost in een recentere versie, RESOLVED WORKSFORME kan de juiste STATUS zijn. Zie RESOLVED voor een gedetailleerde beschrijving van alle mogelijke waarden.
4. VERIFIED: Deze optie is alleen beschikbaar als de huidige bugstatus is OPGELOST (RESOLVED). U kunt een opgeloste (RESOLVED FIXED) bug markeren als GEVERIFIEERD (VERIFIED), wanneer u kunt bevestigen dat deze is opgelost met de versie die in het bugrapport wordt vermeld. Het is ook prettig voor de ontwikkelaar die het probleem heeft opgelost en is een bevestiging dat het probleem nu is opgelost. Anders kan een bugreporter zijn eigen bug die zich in de status RESOLVED WORKSFORME bevindt, markeren als VERIFIED WORKSFORME om te controleren of deze op de een of andere manier is opgelost.
5. INVALID: Er zijn veel redenen waarom kan worden vastgesteld dat een bug ongeldig is, maar dit vereist meestal inbreng van andere QA-leden. Als u een bug tegenkomt waarvan u denkt dat deze ongeldig is, kunt u het beste een second opinion krijgen van het QA IRC-kanaal of een e-mail sturen naar de mailinglijst waarin wordt uitgelegd waarom u denkt dat de bug ongeldig is.
6. UNCONFIRMED: Dit is de status die alle nieuwe bugs krijgen die nog niet door triage beoordeeld zijn. Het kan ook zijn dat die bug dan de status NEEDINFO krijgt als er meer informatie nodig is om de bug te kunnen beoordelen.

ELKE keer dat u wijzigingen aanbrengt, moet u een opmerking plaatsen die beleefd uitlegt waarom u de wijziging hebt aangebracht

Stroomdiagrammen hieronder zijn voorbeelden van hoe u visueel kunt denken aan het instellen van STATUS. Voel ju vrij om uw eigen versie te bewerken en te uploaden als u dat wilt.
PDF bestand
LibreOffice Draw-bestand

Stap 7: Regressie testen

Gebruik oudere versies van LibreOffice om erachter te komen in welke versie de bug is geïntroduceerd.

Download en installeer een aantal oude versies, waarvan de oudste LibreOffice 3.3 is. U moet minimaal één versie hebben van alle hoofdreleaselijnen (3.x, 4.x, 5.x, 6.x...).

U moet zich bewust zijn van wanneer verschillende functies in de software zijn geïntroduceerd om te voorkomen dat u irrelevante testresultaten krijgt. Raadpleeg andere teamleden als u ergens niet zeker van bent.

• Als de bug aanwezig is in versie 3.3.0, stel dan de versie in op "inherited from OOo" en voeg de volgende opmerking toe:

This bug is already present in Libreoffice 3.3.0

Changing version to "inherited from OOo"

• Als de bug niet aanwezig is in 3.3.0, voeg dan "regression" toe aan het trefwoordenveld en voeg de volgende opmerking toe:

This bug is not present in Libreoffice 3.3.0, thus it's a regression

Voor regressies die ouder zijn dan versie 3.5.0, voegt u ook het trefwoord preBibisect toe. Voor nieuwere regressies voegt u het trefwoord bibisectRequest toe en werkt u het versieveld bij zodat deze overeenkomt met de vroegst bekende problematische versie.

• SI-GUI - Eenvoudige GUI-app om parallel te installeren op Windows en Android
• Parallel installeren - Instructies voor het handmatig parallel installeren op Windows, Linux en Mac.
• https://downloadarchive.documentfoundation.org/libreoffice/old/ - Download oude releases, bèta's en alfa's

Stap 8: Prioriteit bug bepalen

We highlighten nu alleen kritieke bugs door CC-ing ontwikkelaars en het toevoegen van trefwoorden. Meer informatie.

Het prioriteren van een bug is relatief subjectief, maar de triager moet altijd proberen consistent te zijn met hoe ze de prioritering van een bug bepalen. Het QA-teamlid triage moet een duidelijk idee hebben van wat elke prioriteitsstatus vormt en vervolgens proberen vast te houden aan die methodologie. Ook is het nuttig om commentaar te geven op de bug na het prioriteren omdat het de bugverslaggever (evenals ontwikkelaars en andere gebruikers) laat weten welk denkproces u heeft gebruikt om de prioriteitsstatus te bedenken.

Om bugs boven medium-normal te prioriteren, moet u worden toegevoegd aan de contributors-groep in Bugzilla. Om dit voor elkaar te krijgen, kunt u contact opnemen met een van de Bugzilla beheerders.

Het onderstaande stroomdiagram toont ruwe richtlijnen over hoe om te gaan met prioritering.

Voorbeeld1 JPG

Vooebeeld1 Draw

Het is meestal gemakkelijker om de ernst van een probleem te bepalen dan te proberen een geschikte prioriteit te bedenken.

Kleine esthetische aanpassingen aan de gebruikersinterface kunnen worden beschouwd als lage prioriteit en trivial'.

Problemen die u boos maken, maar die u op de een of andere manier kunt tolereren of omzeilen, kunnen worden ingesteld op minor'.

Bugs die sommige functionaliteit breken en geen tijdelijke oplossing hebben, zijn normal.

Crashes, vastlopen en vastlopen als gevolg van een specifiek bestand of commando zijn major.

Aanvullende bruikbare (optionele) stappen

Keywords

De Trefwoorden veld bevat trefwoorden (keywords) met betrekking tot de categorisatie van deze bug.

Enkele categorieën hiervan zijn:

• Gebroken functionaliteit in specifieke gebieden: bijv. filter:xxx (filter:ooxml, filter:doc, filter:rtf,...), perf
• Gevraagde of verstrekte foutopsporingsinformatie: bijv. bibisectRequest, bibisected
• Easy Hacks: easyHack, difficultyBeginner, skillCPP

Een interessant trefwoord is needsDevEval. Een easyHack is een bug die hoogstwaarschijnlijk niet lang zal duren om te repareren en kan worden gedaan door een nieuwe ontwikkelaar en / of een ontwikkelaar zonder veel programmeervaardigheden. Als QA moeten we een bug NIET markeren als easyHack omdat het verschillende extra stappen vereist (inclusief het vinden van een ontwikkelaar om de bug te begeleiden). Als u denkt dat een bug kwalificeert als een easyhack, markeer dan als needsDevEval.

Foutrapporten

Het hebben van een crashrapport (ook bekend als backtrace) voor een bug maakt het voor een ontwikkelaar gemakkelijk om te identificeren wat de crash veroorzaakt. Als een crashrapport wordt toegevoegd aan een bugrapport, moet het trefwoord havebacktrace worden toegevoegd aan het veld 'Keywords.

• Debug Informatie
• Hoe krijg ik een backtrace met WinDbg

Meta rapporten

Kijk naar onze bestaande meta-rapporten die rapporten van hetzelfde genre verzamelen. Als u een goede match vindt, voegt u het meta-rapportnummer toe aan het veld Blokken (Blocks) van het rapport dat u triageert.

Commentaar tags

Commentaar-tags fungeren als notities waarmee iedereen een snel overzicht krijgt van de reactiegeschiedenis en de waarde/relevantie van individuele opmerkingen. Klik op de tagtekst in de koptekst van een opmerking, voer uw tag in en druk op enter. Het is niet nodig om het rapport op te slaan. U kunt nieuwe tags bedenken of bestaande tags gebruiken. Het invoerveld voor tags ondersteunt automatisch aanvullen.

Als u een van deze tags invoert, wordt de opmerking standaard verborgen: obsolete, spam, me-too, off-topic, abusive, no-value, bibisection, noise. U kunt een verborgen opmerking weergeven door te klikken op de widget "Commentaarweergave in-/uitschakelen" in de commentaarkop. U kunt ook gewone opmerkingen verbergen en getagde opmerkingen weergeven door op de tagnaam van uw keuze te klikken onder de lijst "Commentaartags" naast de bugbeschrijving (opmerking 0). Klik op Alle opmerkingen uitvouwen om alles weer te geven.

Aanvullende informatie controleren

Als triager moeten we proberen de informatie te controleren die oorspronkelijk door de bugreporter werd gemeld. Dingen om te controleren zijn onder andere:

• Product
• Versie
• Platform

Ontwikkelaars toevoegen aan de CC

Deze stap moet alleen worden uitgevoerd als u zeker weet dat deze belangrijk genoeg is om een ontwikkelaar te mailen met kopie. Als u denkt dat een bug ernstig genoeg is dat het extra aandacht verdient maar misschien niet thuishoort in de categorie Meest vervelende bugs, dan moet u een expert zoeken voor een aanvullende mening. Probeer dit met zorg te gebruiken, want we willen onze deskundige ontwikkelaars niet overspoelen met kleine bug-pings. Om de gebruiker toe te voegen, voegt u eenvoudig zijn naam toe aan de CC-lijst en plaatst een opmerking over de bug die de ontwikkelaars vertelt waarom u ze aan de CC hebt toegevoegd Hoe dan ook, de juiste namen zijn te vinden in de lijst met experts.

QA toevoegen aan de CC

Dit wordt meestal niet gebruikt, maar als u het gevoel hebt dat het toevoegen van uzelf of een ander QA-lid aan de lijst nuttig kan zijn, voel u dan vrij om dit te doen. Nogmaals, zorg ervoor dat u een opmerking toevoegt als u iemand anders aan de lijst toevoegt, anders kunnen ze geïrriteerd raken omdat ze niet weten wat er aan de hand is.

Testen of het in samenhang met andere systemen werkt

Als de testvereiste het openen of opslaan van een bestand met Microsoft Office is en u geen toegang hebt tot de software, kunt u gebruikmaken van Office Web Viewer. Het werkt met Word-, Excel-, PowerPoint- en ODF-documenten. U moet het document ergens uploaden en vervolgens de URL toevoegen aan het einde van deze link:

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

U kunt vervolgens op de Print knop in het bovenste menu en ten slotte Open PDF om toegang te krijgen tot een PDF-weergave van het document. Hiermee kunt u zien hoe het document eruit ziet in de nieuwste versie van Microsoft Office en de PDF delen in Bugzilla.

Bugzilla bijlage links werken met de viewer.

Het gebruiken van de 'live viewer' in Firefox

• Voeg een nieuwe bladwijzer toe
• Stel een aantal Naam in
• Stel de URL in op:

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

• Stel een Keyword in, zoals lv, druk op OK.
• Nu kunt u het trefwoord bladwijzers plus een bugdoc-URL in de URL-balk gebruiken om de bugdoc in de Office Live Viewer te openen:

lv https://bugs.documentfoundation.org/attachment.cgi?id=180059

Aantekeningen over triage voor het QA-team

Hier zijn enkele opmerkingen voor ervaren triagers in de QA/Team. Als u nieuw bent, maak u hier dan geen zorgen over!

Bugrapporten die te lastig zijn voor triage of sluiten

Soms hebben we speciale software of hardware nodig om een bug te reproduceren of we worden geconfronteerd met een andere moeilijkheid die ons ervan weerhoudt om te onderzoeken. Voor deze gevallen hebben wij:

• Een verzameling onbevestigde bugs waar QA-teamleden het moeilijk mee hebben.

De collectie maakt gebruik van de MediaWiki Bugzilla-extensie, die gegevens uit metarapporten en verschillende andere query's haalt.

Extensies

Het is het beste om de maker van de extensie te betrekken bij de triage. De verantwoordelijkheid voor het contact opnemen met de maker ligt bij de bugreporter.

Lees ook:

• Bugrapport extensies

Invloeden van de taal

Soms worden we geconfronteerd met moeilijke onderwerpen met betrekking tot locaties. Er kan een situatie zijn waarin een landelijke norm voor iets afwijkt van de praktijk. In deze gevallen kan het nuttig zijn om de probleemmelder door te verwijzen naar de Unicode Common Locale Data Repository en hun enquêtehulpmiddel.

Voorgestelde volgorde van triage

De onderstaande tabellen geven een voorgestelde volgorde om de triage te benaderen. Het doel van QA is om eerst de ergste bugs te bevestigen.

Tabel per platform (besturingssysteem)

Beschrijving	Alle bugs	Windows	Linux	macOS	Opmerkingen
Bugs die crashes veroorzaken	CrasherAll	CrasherWindows	CrasherLinux	CrashermacOS	Dit zijn bugs die "crash" of een vergelijkbaar woord in de titel van de bug hebben. Hiervan moet de ernst worden ingesteld op Major/Critical, afhankelijk van het aantal gebruikers dat wordt getroffen. QA moet ook kijken of de crash een regressie is of niet en "regressie" toevoegen aan trefwoorden als de bug wordt vastgesteld als een regressie.
Potentiële regressies	possibleRegressionAll	possibleRegresionWindows	possibleRegressionLinux	possibleRegressionmacOS	Als wordt bevestigd dat de bug een regressie is, moet het trefwoord "possibleRegression" worden verwijderd en moet "regression" aan de zoekwoorden worden toegevoegd.
Keyword Regressie	RegressionAll	RegressionWindows	RegressionLinux	RegressionmacOS	De melder van de bug of iemand anders heeft 'regression' in het zoekwoord gezet. Net zo belangrijk als de rij hierboven, maar Bugzilla staat geen "of" -zoekopdracht toe, dus moest het in twee rijen gesplitst worden.
Bugs gerapporteerd als kritiek	CriticalAll	CriticalWindows	CriticalLinux	CriticalmacOS	Alleen gebruikers met speciale bevoegdheden kunnen bugs op kritiek zetten. Kritiek is gereserveerd voor zeer ernstige bugs (zoals gegevensverlies dat veel gebruikers zal treffen). Meer informatie: PriorityFlowChart
Bugs gerapporteerd als 'major'	MajorAll	MajorWindows	MajorLinux	MajormacOS	Alleen gebruikers met speciale rechten kunnen bugs instellen op 'major'. Dat is gereserveerd voor zeer ernstige bugs (zoals gegevensverlies), maar die waarschijnlijk niet veel gebruikers zullen treffen of alleen in bijzondere gevallen met individuele documenten. Meer informatie: PriorityFlowChart.
Alle bugs	AllBugs	AllWindows	AllLinux	AllmacOS	Lijst van alle bugrapporten (geen verbeteringen). Als de bovenstaande bugs als eerste worden aangepakt, hebben de resterende bugs een iets lagere prioriteit om te bevestigen. Suggestie is om deze in chronologische volgorde te doen (oudste eerst, zodat gebruikers die het langst geleden een fout hebben gemeld voorrang krijgen).
Verbeteringsverzoeken	EnhancementAll	EnhancementWindows	EnhancementLinux	EnhancementmacOS	Verbeteringsverzoeken krijgen de laagste prioriteit als geldige verzoeken.

Tabel per component

Beschrijving	Writer	Calc	Impress	Draw	Base	Andere	Opmerking
Bugs gerapporteerd als vastlopers	WriterCrasher	SpreadsheetCrasher	PresentationCrasher	DrawingCrasher	DatabaseCrasher	OtherCrashers	'Kritiek' is alleen voorbehouden aan de ernstigste bugs (zoals het niet kunnen installeren van LibreOffice). Meer informatie: PriorityFlowChart
Potentiële regressies	WriterPosReg	SpreadsheetPosReg	PresentationPosReg	DrawingPosReg	DatabasePosReg	OtherPosReg	Als wordt bevestigd dat de bug een regressie is, moet het trefwoord "possibleRegression" worden verwijderd en moet "regression" aan de zoekwoorden worden toegevoegd.
Keyword Regressie	WriterRegression	SpreadsheetRegression	PresentationRegression	DrawingRegression	DatabaseRegression	OtherRegressions	De melder van de bug of iemand anders heeft 'regression' in het zoekwoord gezet. Net zo belangrijk als de rij hierboven, maar Bugzilla staat geen "of" -zoekopdracht toe, dus moest het in twee rijen gesplitst worden.
Bugs gerapporteerd als kritiek	WriterCritical	SpreadsheetCritical	PresentationCritical	DrawingCritical	DatabaseCritical	OtherCritical	Alleen gebruikers met speciale bevoegdheden kunnen bugs op kritiek zetten. Kritiek is gereserveerd voor zeer ernstige bugs (zoals gegevensverlies dat veel gebruikers zal treffen). Meer informatie: PriorityFlowChart
Bugs gerapporteerd als 'major'	WriterMajor	SpreadsheetMajor	PresentationMajor	DrawingMajor	DatabaseMajor	OtherMajor	Alleen gebruikers met speciale rechten kunnen bugs instellen op 'major'. Dat is gereserveerd voor zeer ernstige bugs (zoals gegevensverlies), maar die waarschijnlijk niet veel gebruikers zullen treffen of alleen in bijzondere gevallen met individuele documenten. Meer informatie: PriorityFlowChart.
Overige bugs	WriterOther	SpreadsheetOther	PresentationOther	DrawingOther	DatabaseOther	AllOther	Dit zijn alle bugs die zijn gemarkeerd als iets onder Major, maar exclusief verbeteringen.
Verbeteringsverzoeken	WriterEnhance	SpreadsheetEnhance	PresentationEnhance	DrawingEnhance	DatabaseEnhance	OtherEnhance	Verbeteringsverzoeken