QA/BugTriage

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

• Domů
• Vývoj
• Design
• QA
• Události
• Dokumentace
• Webové stránky
• Lokalizace
• Přístupnost
• Marketing
• Diverzita
• Nápověda

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

Úvod

Tento dokument poskytuje informace o tom, jak třídit chyby v LibreOffice. Třídění (Triage) je název pro potvrzení, stanovení priority a organizaci hlášení o chybách a je dobrým místem pro nové přispěvatele nebo přispěvatele s omezenými programovacími schopnostmi, aby pomohli LibreOffice stát se lepším produktem pro každého. Třídění je neuvěřitelně důležitý aspekt vývoje, ze kterého mají prospěch uživatelé i vývojáři.

Kde najít další členy QA týmu

Existuje několik míst, kde můžete najít/kontaktovat členy QA týmu, z nichž mnozí mohou pomoci s dotazy ohledně třídní a sami aktivně třídí.

1. E-mailové konference
   • libreoffice-qa@lists.freedesktop.org
   • libreoffice@lists.freedesktop.org
2. IRC kanály na Libera Chat
   • #libreoffice-qa ^IRC://
   • #libreoffice-dev ^IRC://
3. Členové QA
   Zde je seznam členů QA (pokud chcete přispět k QA, můžete přidat své vlastní jméno). Pokud vám uživatel dal svolení kontaktovat je přímo, můžete tak učinit. Také je najdete dost často v chatovacích místnostech, kde něco diskutují.
4. * Seznam členů QA

Kroky ke třídění chyby

Tato část obsahuje seznam kroků nezbytných pro správné třídění. Tento návod má být stručný, odkazy v některých částech poskytnou více informací relevantních pro konkrétní krok. Proces třídění lze v zásadě rozdělit na tři části, z nichž první je „příprava“, druhá je „reprodukce“, třetí je „prioritizace“.

'Přehled kroků'

1. Najděte chyby k třídění
2. Předfiltrujte hlášení o chybách
3. Vyhledejte duplikáty chyb
4. Zkontrolujte informace uvedené v hlášení o chybě
5. Pokuste se o reprodukci chyby
6. Nastavte stav chyby
7. Regresní testování
8. Stanovte prioritu chyby

'Podrobnosti kroků'

Příprava

Obecně jsou při přípravě třídění chyb žádoucí tyto kroky . Nezapomeňte, že na chybách můžete pracovat pouze po přihlášení (prosím vytvořte účet, pokud jej ještě nemáte). A jakmile máte účet, je dobré jít do předvoleb a nastavit 'Automaticky přidat mě do seznamu CC chyb, které změním' na 'Pouze pokud nemají na ně žádnou roli “, pokud chcete být upozorněni pokaždé, když někdo odpoví na některou z hlášení chyb, ke které jste se vyjádřili.

Krok 1: Najděte chyby k třídění

a) Hledání v Bugzille

Přejděte do systému sledování chyb LibreOffice, který se nachází na adrese bugs.documentfoundation.org. Po přihlášení, procházení otevřete problémy podle komponenty nebo proveďte vlastní hledání chyb, které jsou:

a) zařazené v produktu LibreOffice

b) mají status UNCONFIRMED nebo REOPENED

c) přidejte jakákoli další kritéria, podle kterých byste chtěli hledat

Jakmile jste tam, hledejte chybu, kterou chcete třídit. Vlastní hledání chyb lze vytvořit pomocí formuláře pro pokročilé vyhledávání nebo zadáním vyhledávacích dotazů do pole Rychlé hledání (Nápověda pro rychlé vyhledávání Bugzilly). Můžete také použít následující přímé odkazy na vyhledávání. Kliknutím na odkaz se zobrazí stránka s výsledky Bugzilly:

• Chyby hlášené v předchozích 2 týdnech
• Chyby hlášené v předchozím 1 měsíci
• Všechny chyby, které potřebují třídění. (Omezeno na 500 chyb, načtení celého seznamu bude nějakou dobu trvat, protože je to poměrně dlouhý seznam - můžete to změnit!)
• Všechny macOS chyby, které vyžadují potvrzení

Krok 2: Předběžné filtrování hlášení o chybách

Některé chyby vyžadují zvláštní pozornost specifických týmů:

UX vylepšení

Veškeré chyby, které pokrývají vylepšení UI / UX LibreOffice, by měly být dány týmu UX

1. Přidejte klíčové slovo 'needsUXEval'
2. Přidejte toto do seznamu CC: libreoffice-ux-adviselists.freedesktop.org
3. Aktualizujte stav

1. * Pokud požadavek vypadá kompletní a hodnověrný, nastavte 'Status' -> NEW
2. * Pokud se požadavek zdá neúplný nebo potřebuje vysvětlení, 'Status' -> NEEDINFO
3. Zanechte komentář v řádcích:

  Tým UX - podívejte se prosím na toto vylepšení. Dík!

Některé chyby Bugzille vůbec nepatří . Seznam témat, která patří jinam, viz stránka BugReport.

• Pokud je některá z těchto chyb uložena v Bugzille, změňte prosím status 'Status' na RESOLVED NOTOURBUG a do komentáře přidejte následující:

Děkujeme, že jste nás kontaktovali!

Přestože se Bugzilla někdy cítí jako střed vesmíru, existuje několik témat, která musí být hlášena jinde. Správné místo k nahlášení vašeho problému, najdete na wiki stránce BugReport: https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla

Krok 3: Vyhledejte duplikáty

Duplikáty jsou zprávy, které jsou velmi podobné nebo identické, ale jsou hlášeny různými uživateli. Obvykle chcete zachovat stav NEW pro zprávy s nejcennějšími informacemi a ostatní uzavřít jako RESOLVED DUPLICATE (VYŘEŠENÝ DUPLIKÁT). Takže přestože existuje starší zpráva, není třeba ji udržovat otevřenou, pokud obsahuje matoucí nebo neúplné informace. Uzavřené duplikáty automaticky zaznamenává Bugzilla a jsou k dispozici na stránce Nejčastěji hlášené chyby. Při třídění prosím zkontrolujte tento seznam a proveďte rychlé prohledání hlášení v Bugzille, abyste zjistili, zda existují nějaké duplikáty zprávy, kterou zkoumáte. Nemusíte nad tím strávit moc času. Až uvidíte více zpráv, poznáte pravděpodobně duplikáty, aniž byste museli používat vyhledávání.

Pokud najdete duplicitní chybu, přeskočte na krok č. 5

Krok 4: Kontrola informací

Kontrola informací je pro vývoj rozhodující. Měli byste hledat zejména:

1. Jasné a smysluplné shrnutí
2. Jasný popis problému
3. Kroky pro reprodukování problému - pokud to není zřejmé ze shrnutí a / nebo popisu
4. Přílohy - v mnoha případech jsou k reprodukování problému nutné přílohy, pokud nejsou přílohy k dispozice, může to vlastní opravy ztížit
5. Pokud hlášení odkazuje na externí data (snímky obrazovky, dokumenty, screencasty atd.), zkopírujte je a připojte k chybě, aby později nezmizely a nezpůsobily její neopravitelnost.

Pokud nejsou všechny informace správně poskytnuty, přejděte ke kroku č. 5

Krok 5: Pokus o reprodukci

Pokud chyba „prošla“ přípravnými kroky, je čas zkusit tuto chybu reprodukovat.

Udělejte jen toto: Projděte nezbytné kroky a pokuste se reprodukovat chybu, tak jednoduché! Při reprodukci mějte na paměti tyto věci:

1. Zanechal reportér chyb v Bugzille dostatek informací, aby chybu reprodukoval, nebo jste museli podniknout další kroky? Pokud byly potřeba další kroky, přidejte komentář k popisu těchto dalších kroků.
2. Vedla vaše reprodukce ke stejnému výsledku, něčemu podobnému, ale ne identickému, nebo všechno fungovalo bezchybně?

Krok 6: Nastavení stavu

Tato část je posledním „povinným“ krokem úspěšného třídění a může být provedena pouze poté, co jsou provedeny kroky # 1– # 4 (nebo # 3, pokud # 4 nelze použít).

STATUS chyby závisí na vašich výsledcích z výše uvedených kroků. Níže je uveden stručný popis použití jednotlivých stavů.

1. NEW: Potvrzená chyba, všechny potřebné informace jsou zde
2. NEEDINFO: Ve zprávě o chybách nejsou zahrnuty všechny informace potřebné k pokusu o replikaci. Požádejte konkrétní osobu o konkrétní informaci v komentáři.
3. RESOLVED: Tato kategorie nabízí několik možností. Například, pokud byl problém již nahlášen, můžete jej označit jako RESOLVED DUPLICATE. Nebo pokud můžete replikovat chybu, jak je popsáno, ale je již opravena v novější verzi, je příslušný status RESOLVED WORKSFORME. Podrobný popis všech možných hodnot naleznete v RESOLVED.
4. VERIFIED: Tato možnost je k dispozici, pouze pokud je aktuální stav chyby RESOLVED (VYŘEŠENO). VYŘEŠENOU OPRAVENOU chybu můžete označit jako VERIFIED (VERIFIKOVÁNO), pokud můžete potvrdit, že je chyba opravena verzí uvedenou v hlášení o chybě. Pro vývojáře, který problém vyřešil, je to užitečné a je to i potvrzení, že problém je nyní vyřešen. V opačném případě může reportér chyb označit svou vlastní chybu, která je ve stavu RESOLVED WORKSFORME jako VERIFIED WORKSFORME, aby bylo ověřeno, že je to nějak opraveno.
5. INVALID: Existuje mnoho důvodů, proč lze chybu určit jako neplatnou, ale obvykle to vyžaduje vstup od ostatních členů QA. Pokud narazíte na chybu, o které se domníváte, že není platná, je nejlepší získat druhý názor od QA IRC nebo poslat e-mail do mailing listu s vysvětlením, proč se domníváte, že chyba není platná.
6. UNCONFIRMED: Toto je stav daný všem novým chybám, které neproběhly procesem třídění. Tato chyba může být také ve stavu NEEDINFO.

Kdykoli provedete změny, měli byste vložit komentář, který přehledně vysvětluje, proč jste změnu provedli

Vývojové diagramy níže jsou příklady toho, jak vizuálně přemýšlet o nastavení stavu chyby. Pokud chcete, můžete upravit a nahrát svou vlastní verzi.
soubor PDF
LibreOffice Draw file

Krok 7: Regresní testování

Použijte starší verze LibreOffice a zjistěte, zda chyba existovala již od začátku LibreOffice.

Stáhněte si a nainstalujte několik starých verzí, z nichž nejstarší je LibreOffice 3.3. Minimálně byste měli mít jednu verzi ze všech hlavních řad vydání (3.x, 4.x, 5.x, 6.x ...).

Musíte si být vědomi toho, kdy byly do softwaru zavedeny různé funkce, abyste se vyhnuli irelevantnímu výsledku testu. Pokud si nejste jisti, obraťte se na další členy týmu.

• Pokud je chyba přítomna ve verzi 3.3.0, nastavte verzi na "inherited from OOo (zděděnou z OOo)" a přidejte tento komentář:

This bug is already present in Libreoffice 3.3.0 (český překlad: Tato chyba je již v Libreoffice 3.3.0)

  Změna verze na „inherited from OOo“

• Pokud se chyba nevyskytuje v 3.3.0, přidejte do pole klíčových slov "regression" (regrese) a přidejte tento komentář:

This bug is not present in Libreoffice 3.3.0, thus it's a regression (český překlad: Tato chyba se v Libreoffice 3.3.0 nevyskytuje, jedná se tedy o regresi)

  U regresí starších než verze 3.5.0 přidejte klíčové slovo preBibisect. Pro novější regrese přidejte klíčové slovo bibisectRequest a aktualizujte pole verze tak, aby odpovídalo nejstarší známé problematické verzi.

• SI-GUI - Jednoduchá aplikace GUI pro paralelní instalaci na Windows a Android
• Installing in parallel - Pokyny k ruční paralelní instalaci na Windows, Linux a Mac.
• https://downloadarchive.documentfoundation.org/libreoffice/old/ - Stáhněte si stará vydání, beta a alfa

Krok 8: Prioritizace chyby

V současné době upozorňují na kritické chyby a přidávají klíčová slova pouze CC vývojáři. Viz více informace níže.

Stanovení priority chyby je relativně subjektivní, ale triager by se měl vždy snažit být konzistentní v tom, jak určí prioritu chyby. Členové týmu QA triaging by měli mít jasnou představu o tom, co představuje každý prioritní stav, a poté se pokusit držet se této metodiky. Také je užitečné po stanovení priority chyby přidat komentář, což umožňuje reportérovi chyb (stejně jako vývojářům a dalším uživatelům) poznat, jaký myšlenkový proces jste použili pro stanovení stavu priority.

Chcete-li upřednostnit chyby nad středně normální, je třeba, abyste byl přidán do skupiny přispěvatelů v Bugzille. Chcete-li to provést, kontaktujte prosím někoho z administrátorů Bugzilly.

Níže uvedený vývojový diagram ukazuje hrubé pokyny, jak zacházet s prioritami.

Příklad 1 JPG

Příklad 1 Draw

Obvykle je snazší určit závažnost problému, než se pokusit vymyslet vhodnou prioritu.

Malé estetické vylepšení uživatelského rozhraní lze považovat za nízkou prioritu a triviální závažnost.

Problémy, které vás rozčilují, ale můžete je nějak tolerovat nebo nějak obejít, lze nastavit na minor (menší) závažnost.

Chyby, které narušují některé funkce a nemají řešení, mají normal (normální) závažnost.

Havárie, zablokování a zamrznutí způsobené konkrétním souborem nebo příkazem mají major (velkou) závažnost.

Další užitečné (volitelné) kroky

Klíčová slova

Pole Keywords (klíčová slova) obsahuje klíčová slova týkající se kategorizace této chyby.

Některé kategorie klíčových slov zahrnují:

• Porušená funkcionalita v konkrétních oblastech: např. filter:xxx (filter:ooxml, filter:doc, filter:rtf, ...), perf
• Požadované nebo poskytované informace o ladění: např. bibisectRequest, bibisected
• Easy Hacks: easyHack, difficultyBeginner, skillCPP

Jedním ze zajímavých klíčových slov je needsDevEval. EasyHack je chyba, jejíž oprava pravděpodobně nezabere moc času a může být provedena novým vývojářem nebo vývojářem s méně programovacími dovednostmi. Jako QA bychom NEMĚLI označit chybu jako easyHack, protože vyžaduje několik dalších kroků (včetně nalezení vývojáře jako mentora pro chybu). Pokud si myslíte, že lze chybu označit jako "easyhack", označte ji jako needsDevEval.

Hlášení o pádech

Díky chybové zprávě o pádu (aka backtrace) vývojáři snadno zjistí, co způsobuje pád aplikace. Pokud je zpráva o pádu přidána do zprávy o chybě, mělo by se do pole Keywords přidat klíčové slovo havebacktrace.

• QA/BugReport/Debug Information
• How to get a backtrace with WinDbg

Meta zprávy

Podívejte se na naše existující meta zprávy, které shromažďují zprávy stejného žánru. Pokud najdete vhodnou meta zprávu, přidejte číslo této meta zprávy do pole Bloky ve zprávě, kterou právě upravujete.

Comment tags (Štítky komentářů)

Štítky komentářů fungují jako poznámky, které pomáhají každému získat rychlý přehled o historii komentářů a hodnotě / relevanci jednotlivých komentářů. Klikněte na text štítku v záhlaví komentáře, zadejte štítek a stiskněte klávesu Enter. Není třeba zprávu ukládat. Můžete vymýšlet nové štítky nebo používat existující štítky. Pole pro zadání štítku podporuje automatické doplňování.

Zadáním jednoho z těchto štítků bude komentář ve výchozím nastavení skrytý: obsolete, spam, me-too, off-topic, abusive, no-value, bibisection, noise. Skrytý komentář můžete zobrazit kliknutím na widget "Přepnout zobrazení komentáře" v záhlaví komentáře. Můžete také skrýt pravidelné komentáře a zobrazovat označené komentáře kliknutím na název štítku podle svého výběru v seznamu "Štítky komentářů" vedle popisu chyby (komentář 0). Všechny komentáře zobrazíte kliknutím na Rozbalit všechny komentáře.

Kontrola dodatečných informací

Jako triager bychom se měli pokusit zkontrolovat informace, které původně hlásil reportér chyb. Kontrola zahrnuje:

• Produkt
• Verze
• Platforma

Přidání vývojáře do seznamu CC

Tento krok by měl být proveden pouze v případě, že jste si jisti, že je to důležité pro CC vývojáře. Pokud si myslíte, že chyba je natolik vážná, že si zaslouží zvláštní pozornost, ale možná nepatří do kategorie Most Annoying Bugs (nejotravnější chyby), měli byste vyhledat odborníka pro dodatečné posouzení. Prosím, používejte toto s rozmyslem, protože nechceme zaplavit naše odborné vývojáře drobnými chybami. Chcete-li přidat uživatele, přidejte jeho jméno do seznamu CC a 'přidejte komentář k chybě a řekněte vývojářům, proč jste jej přidali do CC'. Každopádně správná jména však najdete v seznamu odborníků.

Přidání QA do seznamu CC

Většinou se nepoužívá, ale pokud si myslíte, že může být užitečné, přidat sebe nebo jiného člena QA do seznamu, neváhejte to udělat. Pokud do seznamu přidáváte někoho jiného, nezapomeňte přidat komentář, jinak by mohli být podrážděni tím, že nevědí, co se děje.

Testování interoperability

Pokud je podmínkou testování otevření nebo uložení souboru pomocí Microsoft Office a nemáte přístup k tomuto softwaru, můžete použít Office Web Viewer. Pracuje s dokumenty Word, Excel, PowerPoint a ODF. Dokument je třeba někam nahrát a pak přidat adresu URL na konec tohoto odkazu:

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

Poté můžete kliknout na tlačítko Tisk v horní nabídce a nakonec na Otevřít PDF, čímž získáte přístup k zobrazení dokumentu ve formátu PDF. To vám umožní jednak vidět, jak dokument vypadá v nejnovější verzi Microsoft Office, a také sdílet PDF v Bugzille.

Odkazy na přílohy Bugzilla fungují s prohlížečem.

Chcete-li pohodlně používat živý prohlížeč ve Firefoxu

• Přidejte novou záložku
• Nastavte nějaký Název
• Nastavte URL na:

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

• Nastavte Klíčové slovo, například lv, stiskněte OK.
• Nyní můžete použít klíčové slovo záložky a URL adresu přílohy v bugu v panelu URL a otevřít přílohu v prohlížeči Office Live:

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

Zvláštní poznámky ke třídění pro tým QA

Zde jsou některé poznámky pro pokročilé Triagers v QA/Team. Pokud jste nový, nedělejte si s tím starosti!

Hlášení chyb, které je obtížné třídit nebo uzavřít

Někdy pro reprodukci chyby potřebujeme speciální software nebo hardware, nebo čelíme jiným problémům, které nám brání ve vyšetřování. Pro tyto případy máme:

• soubor UNCONFIRMED chyb, se kterými mají členové týmu QA potíže.

Tento soubor používá rozšíření MediaWiki Bugzilla, které stahuje data z meta zpráv a různých dalších dotazů.

Rozšíření

Nejlepší je zapojit tvůrce rozšíření do třídění. Odpovědnost za kontaktování tvůrce má reportér chyb.

Čtěte také:

• QA/BugReport/Extensions

Kontroverze týkající se národního prostředí

Někdy se potýkáme s horkými tématy souvisejícími s místním nastavením. Může nastat situace, kdy se národní standard pro něco liší od skutečné praxe. V těchto případech může být užitečné nasměrovat reportéra problému do Unicode Common Locale Data Repository a jejich průzkumový nástroj.

Navrhovaný způsob třídění

Níže uvedené tabulky představují navržený způsob třídění. Cílem QA je nejprve potvrdit nejhorší chyby.

Tabulka podle platformy (OS)

Popis	Všechny chyby	Windows	Linux	macOS	Komentář
Hlášení o pádech aplikace	CrasherAll	CrasherWindows	CrasherLinux	CrashermacOS	Jedná se o chyby, které mají v názvu chyby „havárie“ nebo podobné slovo. V případě havárií by závažnost měla být nastavena na Major/Critical v závislosti na tom, kolik uživatelů bude ovlivněno. Také QA by se měl podívat na to, zda je selhání regresí nebo ne, a přidat klíčové slovo „regrese“, pokud je chyba určena jako regrese.
Potenciální regrese	possibleRegressionAll	possibleRegresionWindows	possibleRegressionLinux	possibleRegressionmacOS	Pokud je chyba regrese, mělo by být klíčové slovo "possibleRegression" (možná regrese) odstraněno a do klíčových slov by mělo být přidáno slovo "regression" (regrese).
Klíčové slovo Regression (regrese)	RegressionAll	RegressionWindows	RegressionLinux	RegressionmacOS	Reportér chyby nebo někdo jiný uvedl regresi jako klíčové slovo. Stejně důležité jako výše uvedený řádek, ale Bugzilla neumožňuje vyhledávání "or" (nebo), takže se to muselo rozdělit do dvou řádků.
Chyby hlášené jako Critical (kritické)	CriticalAll	CriticalWindows	CriticalLinux	CriticalmacOS	Pouze uživatelé se speciálním oprávněním mohou nastavit status chyby na Critical. Critical (kritický) je vyhrazeno pro velmi závažné chyby (jako je ztráta dat, která ovlivní mnoho uživatelů). Pokyny viz PriorityFlowChart
Chyby hlášené jako Major (velké)	MajorAll	MajorWindows	MajorLinux	MajormacOS	Pouze uživatelé se speciálním oprávněním mohou nastavit status chyby na Major (velká). Stav Major je vyhrazen pro velmi závažné chyby (jako je ztráta dat), které však pravděpodobně neovlivní mnoho uživatelů nebo se děje pouze v některých případech s jednotlivými dokumenty. Pokyny viz PriorityFlowChart.
Všechny chyby	AllBugs	AllWindows	AllLinux	AllmacOS	Seznam všech hlášení o chybách (bez vylepšení). Pokud jsou výše uvedené chyby vyřešeny jako první, pak zbývající budou mít pro potvrzení o něco nižší prioritu. Navrhuje se potvrzovat je v chronologickém pořadí (nejstarší jako první, takže uživatelé, kteří ohlásili chybu nejdříve, dostanou prioritu).
Žádosti o vylepšení	EnhancementAll	EnhancementWindows	EnhancementLinux	EnhancementmacOS	Žádosti o vylepšení mají při potvrzení platnosti požadavku nejnižší prioritu.

Tabulka podle komponenty

Popis	Writer	Calc	Impress	Draw	Base	Ostatní	Komentář
Chyby hlášené jako pád systému	WriterCrasher	SpreadsheetCrasher	PresentationCrasher	DrawingCrasher	DatabaseCrasher	OtherCrashers	'Critical (Kritická)' závažnost je vyhrazena pouze pro nejzávažnější chyby (jako je nemožnost nainstalovat LibreOffice). Pokyny viz PriorityFlowChart
Potenciální regrese	WriterPosReg	SpreadsheetPosReg	PresentationPosReg	DrawingPosReg	DatabasePosReg	OtherPosReg	Pokud je chyba regrese, mělo by být klíčové slovo "possibleRegression" (možná regrese) odstraněno a do klíčových slov by mělo být přidáno slovo "regression" (regrese).
Klíčové slovo Regression (regrese)	WriterRegression	SpreadsheetRegression	PresentationRegression	DrawingRegression	DatabaseRegression	OtherRegressions	Reportér chyby nebo někdo jiný uvedl regresi jako klíčové slovo. Stejně důležité jako výše uvedený řádek, ale Bugzilla neumožňuje vyhledávání "or" (nebo), takže se to muselo rozdělit do dvou řádků.
Chyby hlášené jako Critical (kritické)	WriterCritical	SpreadsheetCritical	PresentationCritical	DrawingCritical	DatabaseCritical	OtherCritical	Pouze uživatelé se speciálním oprávněním mohou nastavit status chyby na Kritický. Critical (kritický) je vyhrazeno pro velmi závažné chyby (jako je ztráta dat, která ovlivní mnoho uživatelů). Pokyny viz PriorityFlowChart
Chyby hlášené jako Major (velké)	WriterMajor	SpreadsheetMajor	PresentationMajor	DrawingMajor	DatabaseMajor	OtherMajor	Pouze uživatelé se speciálním oprávněním mohou nastavit status chyby na Major (velká). Stav Major je vyhrazen pro velmi závažné chyby (jako je ztráta dat), které však pravděpodobně neovlivní mnoho uživatelů nebo se děje pouze v některých případech s jednotlivými dokumenty. Pokyny viz PriorityFlowChart.
Všechny ostatní chyby	WriterOther	SpreadsheetOther	PresentationOther	DrawingOther	DatabaseOther	AllOther	Toto jsou všechny chyby, které jsou označeny jakkoliv mimo Major (velké), ale nezahrnují Enhancements (vylepšení)
Žádosti o vylepšení	WriterEnhance	SpreadsheetEnhance	PresentationEnhance	DrawingEnhance	DatabaseEnhance	OtherEnhance	Žádosti o vylepšení