QA/BugTriage/fr

    From The Document Foundation Wiki
    < QA
    This page is a translated version of the page QA/BugTriage and the translation is 13% complete.
    Outdated translations are marked like this.

    TDF LibreOffice Document Liberation Project Blogs communautaires Weblate Nextcloud Redmine Ask LibreOffice Donner

    Other languages:


    Ce document fournit des informations sur le processus de tri des bugs de LibreOffice. Le tri est le nom donné pour confirmer, donner une priorité et organiser les rapports de bugs et c'est un bon endroit pour commencer à contribuer et/ou si l'on a des capacités de programmation limitées afin d'aider LibreOffice à devenir un meilleur produit pour chacun. Le tri est un aspect extrèmement important du développement qui bénéficie tant aux utilisateurs qu'aux développeurs. Des détails sont également disponibles sur Comment reporter des bugs LibreOffice.

    Où trouver d'autres membres de l'équipe QA

    Il y a plusieurs endroits où vous pouvez entrer en contact avec des membres de l'équipe QA dont plusieurs d'entre eux seront à même de répondre à vos questions et sont très actifs eux-même dans le tri des bugs.
    1. Mailing Listes

    • libreoffice-qa@lists.freedesktop.org
    • libreoffice@lists.freedesktop.org
    • qa@fr.libreoffice.org (liste en français)

    2. IRC

    • libreoffice-qa
    • libreoffice-dev
    • libreoffice-fr (canal en français)

    3. Membres de l'équipe QA
    Voici une liste des membres de l'équipe QA (soyez libre d'ajouter votre nom si vous avez l'intention de contribuer à la QA). Si l'utilisateur vous a donné la permission de les contacter directement, soyez libre de le faire, vous les trouverez très souvent sur le canal IRC.

    This document provides information on how to triage bugs for LibreOffice. Triaging is the name given for confirming, prioritizing, and organizing bug reports and is a good place for new contributors and/or contributors with limited programming abilities to help LibreOffice become a better product for everyone. Triaging is an incredibly important aspect of development that benefits users and developers alike.

    Étapes pour trier un bug

    There are a few places where you can find/contact members from the QA team, many of whom can help with triaging questions and are actively triaging themselves.

    1. Mailing Lists
      • libreoffice-qa@lists.freedesktop.org
      • libreoffice@lists.freedesktop.org
    1. IRC Channels on Libera Chat
    1. QA Members
      Here is a list of QA members (feel free to add your own name if you intend on contributing to QA). If the user has given you permission to contact them directly, feel free to do so. Also you'll find them hanging out in the chat rooms somewhat frequently.

    Cette section liste les étapes nécessaires afin de réaliser un tri correct. Ce guide tente d'être précis, les liens de certaines sections fourniron des informations complémentaires relatives à une étape particulière. Le processus de tri peut être essentiellement séparé en trois parties, la première étant la "préparation", la seconde la "reproduction", la troisième la "définition de priorité".

    This section lists the steps necessary in order to triage correctly. This guide aims to be concise, links in some sections will provide more information relevant to the particular step. The triage process can be essentially broken up into three parts, the first being "preparation" the second being "reproducing" the third being "prioritization".

    Résumé des étapes

    1. Trouver des bugs à trier
    2. Rechercher les doublons de ce bug
    3. Vérifier les informations fournies dans le rapport de bug
    4. Essayer de reproduire le bug
    5. Définir le statut du bug
    6. Définir la priorité du bug
    7. Notifier les développeurs -- Nécessaire uniquement dans des cas très spécifiques si le bug semble être un bloqueur ou critique.
    1. Find Bugs to Triage
    2. Pre-filter Bug Reports
    3. Search for Duplicates of Bug(s)
    4. Check Information Provided in Bug Report
    1. Attempt to Reproduce Bug
    2. Set Bug Status
    3. Regression Testing
    4. Prioritize Bug

    Détails des étapes

    Préparation

    En général, vous suivrez toujours ces étapes dans la préparation du tri des bugs Rappelez-vous que vous ne pouvez travailler sur des bugs que lorsque vous êtes connecté sur (veuillez créer un compte si vous n'en avez pas déjà un).

    Preparation

    In general you'll always want to do the following steps in preparing to triage bugs. Remember that you can work on bugs only when logged in (please create an account if you do not already have one). And once you have an account, it is good to go to your preferences and set 'Automatically add me to the CC list of bugs I change' to 'Only if I have no role on them' if you want to be notified whenever someone replies in any of the bug reports you commented in.

    Étape 1. Trouver un bug à trier

    a) Recherche FreeDesktop

    Naviguez jusq'au système de traqueur de bugs de LibreOffice disponible sur bugs.documentfoundation.org. Après vous être connecté browse ouvrez les issues par composant ou faites une rechercher personnalisée sur les bugs qui :

    a) sont remplis dans le produit LibreOffice

    b) ont un statut UNCONFIRMED ou REOPENED

    c) ajoutez tout autre critère sur lequel vous souhaitez faire une requête

    Une fois que vous en êtes là, recherchez les bugs que vous souhaitez trier. La recherche personnalisée de bugs peut être réalisée en utilisant Advanced Search form ou en saisissant les termes de la recherche dans le champ de recherche rapide (Bugzilla Quick Search help). Vous pouvez également suivre ces liens directs de recherche, cliquer sur le lien afficher la page de résultat Bugzilla

    b) Google Documents Bug Groups

    Nous expérimentons un document partagé qui regroupe les bugs. N'hésitez pas à le consulter et vous attribuer une feuille (il y a quelque chose comme 1-50 bugs par feuille, tous organisés par "composants" (ie. writer, feuille de calcul, etc...))

    UX Enhancements

    Any reports which cover enhancements to the UI/UX of LibreOffice should be given to the UX Team. This should be done only at a point where it is clear what the reporter wants. Prefer to leave the status as UNCONFIRMED. Only use NEW, if you feel the proposed change should obviously be implemented and the remaining question is how.

    1. Leave a comment along the lines of:
    UX Team -- please take a look at this enhancement. Thanks!

    Some bugs don't belong in Bugzilla at all. For a list of topics that belong elsewhere, see the BugReport page.

    • If one of these bugs is filed in Bugzilla, please change the Status to RESOLVED NOTOURBUG and add the following in a comment:

    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

    Step 2. Rechercher les doublons

    Les doublons sont des bugs marqués RESOLVED DUPLICATE qui sont très similaire ou identique mais rapportés par différents utilisateurs. Ces bugs sont automatiquement comptés par Bugzilla et disponibles sur la page Such bugs are automatically counted by Bugzilla and available at page des bugs les plus fréquemment rapportés. Lors du tri, veuillez vérifier cette liste et faire une recherche dans les bugs bugzilla pour s'il n'y a pas de doublons du bug que vous avez, mais n'y passez pas cependant trop de temps. Au fur et à mesure que vous verrez plus de bugs, vous serez à même de vous rappeler de ceux que vous avez déjà vus et pourrez facilement fermer le plus récent des deux. En général, minimiser le nombre de doublons entrés dans Bugzilla économisera du temps pour l'équipe de QA.

    Duplicates are reports which are very similar or identical, but reported by different users. You typically want to keep the NEW status for the report with the most valuable information and close others as RESOLVED DUPLICATE. So even though an older report exists, there is no need to keep it open, if it contains confusing or incomplete information.

    Closed duplicates are automatically counted by Bugzilla and available at Most Frequently Reported Bugs page. When triaging please, check that list and do a quick search through reports in Bugzilla to see if there are any duplicates of the report you are examining. You don't need to spend a lifetime on this. As you see more reports you may start spotting duplicates without having to use the search.

    Si vous trouvez un doublon, sautez à l'étape #5

    Step 3. Vérifier les informations

    Vérifier les informations est critique pour le développement. Vous devez vérifier les informations suivantes :

    1. Un résumé clair et significatif
    2. Une description claire du problème
    3. Des étapes pour reproduire le problème -- si ce n'est pas déjà claire dans le sommaire ou la description
    4. Attachements -- dans la plupart des cas, un attachement est nécessaire à la reproduction du problème, si un attachement n'est pas fourni, cela peut entraver la correction du bug.

    Checking information is critical for development. What you should look for is the following:

    1. Clear and meaningful summary
    2. Clear problem description
    1. Steps to reproduce the problem -- if not clear from summary and/or description
    2. Attachments -- in many cases attachments are needed to reproduce the problem, if attachment(s) are not provided this can hinder proper fixes
    3. If the report refers to external data (screenshots, documents, screencasts, etc.), copy and attach them to the bug, so they don't vanish later and eventually render it unreproducible.

    Si toutes les informations ne sont pas fournies, allez à l'étape #5

    Step 4. Essayer de reproduire

    Si le bug a "passé" les étapes de préparation, il est temps d'essayer de le reproduire.
    Faites just cela, suivez les étapes nécessaires et essayez de reproduire le bug, c'est simple ! Lorsque vous le reproduisez, gardez ceci en tête :

    1. Est-ce que le rapporteur du bug a laissé suffisemment d'informations pour reproduire le bug ou avez-vous dû ajouter des étapes supplémentaires ? Si des étapes supplémentaires sont nécessaires, ajoutez un commentaire pour les décrire.
    2. Est-ce que votre reproduction a amené au même résultat, à quelque chose de similaire mais pas identique Did your reproduction result in the same thing, something similar but not identical, ou est-ce que tout a fonctionné parfaitement ?

    If the bug "passed" the Preparation steps it's time to try to reproduce the bug.

    Do just that: Go through the steps necessary and try to reproduce the bug, that simple! When you reproduce it, keep these things in mind:

    1. Did the bug reporter leave enough information in Bugzilla itself to reproduce the bug, or did you have to take extra steps? If extra steps were needed, add a comment to describe the extra step(s).
    2. Did your reproduction lead to the same result, something similar but not identical, or did everything work flawlessly?

    Step 5. Définir le statut

    Cette section est la dernière étape "nécessaire" pour un tri de bug correct et ne peut être réalisée qu'après les étapes #1 - #4 (ou #3 si #4 n'est pas applicable).

    This section is the last "mandatory" step of a successful triage and can only be done once steps #1–#4 are done (or #3 if #4 isn't applicable).

    Le STATUT du bug est dépendant des résultats des étapes ci-dessus. Vous trouverez ci-dessous une description courte de quand utiliser chaque statut.

    1. NEW - bug confirmé, toutes les informations nécessaires sont présentes
    2. NEEDINFO - Toutes les informations nécessaires à la réplication du bug ne sont pas présentes dans le rapport. Veuillez demander à la personne concernée les informations particulières dans le commentaire.
    3. RESOLVED - Cette catégorie vient avec plusieurs options, si vous ne pouvez pas reproduire le bug RESOLVED WORKSFORME est le STATUT approprié, voir ICI pour plus d'informations.
    4. INVALID - Il y a de nombreuses raisons pour lesquelles un bug peut être déterminé comme non valide mais cela réclame en général un avis d'autres membres de l'équipe QA. Si vous rencontrez un bug que vous pensez être non valide, le mieux est d'obtenir un second avis sur le canal IRC QA ou d'envoyer un mail à la mailing liste expliquant pourquoi vous pensez que ce bug n'est pas valide.
    5. UNCONFIRMED - C'est le statut donné à tout nouveau bug qui n'a pas encore été trié. Notez que ce bug peut aussi avoir le statut NEEDINFO.
    1. NEW: Confirmed bug, all information necessary is there
    2. NEEDINFO: All information needed to attempt replication is not included in the bug report. Please ask a particular person for a particular information in a comment.
    3. RESOLVED: This category comes with several options. For example, if the issue has already been reported, you can mark it as RESOLVED DUPLICATE. Or if you can replicate the bug as described, but it is already fixed in a more recent version, RESOLVED WORKSFORME might be an appropriate STATUS. See RESOLVED for a detailed description of all possible values.
    4. VERIFIED: This option is only available when the current bug status is RESOLVED. You can mark a RESOLVED FIXED bug as VERIFIED, when you can confirm it is fixed with the version mentioned in the bug report. It is also pleasant for the developer who fixed the issue, and is a confirmation the problem is solved now. Otherwise a bug reporter can mark their own bug that is in RESOLVED WORKSFORME state as VERIFIED WORKSFORME to verify it is somehow fixed.
    5. INVALID: There are many reasons why a bug can be determined to be invalid, but this usually requires input from other QA members. If you come across a bug that you believe to be invalid, best bet is to get a second opinion from the QA IRC channel or send an email out to the mailing list explaining why you believe the bug to be invalid.
    6. UNCONFIRMED:

    This is the status given to all new bugs that have not gone through triage process. Note that such bug might be also in NEEDINFO state.

    CHAQUE fois que vous faites une modification sur le bug, vous devez ajouter un commentaire expliquant poliment pourquoi vous avez fait cette modification

    Les diagrammes ci-dessous sont des exemples de comment penser visuellement la définition du Statut, n'hésitez pas à éditer et mettre en ligne votre propre version si vous le souhaitez.
    Example 1 PDF
    Example 1 Draw

    Step 7: Regression Testing

    Use older versions of LibreOffice to find out whether the bug has been introduced since LibreOffice began.

    Download and install a number of old versions, the oldest being LibreOffice 3.3. At a minimum you should have one version from all the main release lines (3.x, 4.x, 5.x, 6.x...).

    You have to have some awareness of when various features were introduced into the software to avoid getting irrelevant test results. Please consult other team members, if you are unsure of something.

    • If the bug is present in version 3.3.0, set version to "inherited from OOo" and add the following comment:

    This bug is already present in Libreoffice 3.3.0 

    Changing version to "inherited from OOo"
    • If the bug is not present in 3.3.0 add "regression" to the keywords field and add the following comment:

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

    For regressions that are older than version 3.5.0, also add the keyword preBibisect. For newer regressions add the keyword bibisectRequest and update the version field to match the earliest known problematic version.

    Step 6. Définir la priorité

    Actuellement, nous mettons en avant uniquement les bugs critiques en mettant en CC les développeurs, en ajoutant une entrée spécial au Whiteboard, des mots-clé et en mettant à jour le MAB. Voir ci-dessous pour plus d'informations.

    We currently highlight only critical bugs by CC-ing developers and adding keywords. See below for more information.

    La définition de priorité est actuellement un sacré bazar, mais comme trieurs, nous devons toujours activement essayer d'améliorer les choses. Mettre une priorité à un bug est relativement subjectif mais le trieur doit toujours essayer d'être cohérent avec la façon d'attribuer une priorité. Les membres de l'équipe QA doivent avoir une idée claire de ce qui constitue chaque priorité et ensuite essayer de s'en tenir à cette méthodologie.

    Il est également très important de laisser un commentaire après avoir défini la priorité afin que le rapporteur (ainsi que les développeurs et les autres utilisateurs) prenne connaissance du processus de pensée que vous avez utilisé pour arriver à ce statut de priorité.

    Les diagrammes ci-dessous sont des examples de représentation visuelle de la définition des statuts, n'hésitez pas à les éditer ou à mettre en ligne votre propre version si vous le souhaitez.

    Example 1 JPG

    Example 1 Draw

    It is usually easier to determine the severity of an issue than try to think of a suitable priority.

    Small aesthetic tweaks to the UI can be considered low priority and trivial severity.

    Problems that make you angry, but you can tolerate or work around somehow can be set to minor severity.

    Bugs that break some functionality and do not have a workaround are normal severity.

    Crashes, hangs and freezes resulting from a specific file or command are major severity.

    Étapes supplémentaires utiles (facultatives)

    Mots-clé

    Utilisez le mot-clé regression si la version mineure précédente fonctionnait correctement. Veuillez ne pas noter comme des régressions des bugs plus anciens.

    Les régressions récentes sont généralement très ennuyeuses pour les utilisateurs affectés et plus facile à réparer. Elles sont donc traitées avec une priorité plus importante par les développeurs. D'un autre côté, si une régression met des mois ou des années à être rapportée, c'est que cela doit être une fonctionnalité moins utilisée et que les utilisateurs y sont habitués et a donc moins d'importance.

    Keywords

    The Keywords field holds Keywords pertaining to the categorization of this bug.

    Some categories of Keywords include:

    One interesting Keyword is needsDevEval. An easyHack is a bug that will most likely not take long to fix and can be done by a new developer and/or a developer without a lot of programming skills. As QA we should NOT mark a bug as easyHack as it requires several additional steps (including finding a developer to mentor for the bug). If you think a bug qualifies as an easyhack, mark as needsDevEval.

    Crash reports

    Having a crash report (aka backtrace) for a bug makes it easy for a developer to identify what is causing the crash. If a crash report is added to a bug report, the havebacktrace keyword should be added to the Keywords field.

    Meta reports

    Look at our existing meta reports that collect reports of the same genre. If you find a good fit, add the meta report number to the Blocks field of the report you are triaging.

    Statuts du Whiteboard

    Whiteboard statut sont une liste de statuts facultatifs qui ont été déterminés comme étant utiles à affiner les requêtes. Certains de ces statuts ont une attention spéciale de la part d'un groupe de développeurs. Nous pouvons les diviser par objet :

    Un des statuts intéressant du Whiteboard est needsDevEval. Un EasyHack qui probablement ne prendra pas très longtemps à être corrigé par un nouveau développeur et/ou par un développeur qui n'a pas de grandes capacités de développement. En tant que membre de la QA nous ne devons PAS marqué un de ces bugs comme EasyHack parce que cela requiert plusieurs étapes supplémentaires (incluant de trouver un développeur mentor & faire des backtrace). Si vous pensez qu'un bug peut être qualifié comme easyhack, marquez-le commme PROPOSEDASYHACK et envoyez ensuite un mail à la mailing liste des développeurs ayant pour sujet POSSIBLE EASY HACK FDO#.

    obsolete, spam, me-too, off-topic, abusive, no-value, bibisection, noise.

    You can show a hidden comment by clicking on the "Toggle comment display" widget in the comment header. You can also hide regular comments and show tagged comments by clicking on the tag name of your choosing under the "Comment Tags" list next to the bug description (comment 0). Click Expand all comments to show everything.

    Vérifier des informations supplémentaires

    En tant que trieur, nous devons vérifier les informations qui sont rapportées originellement par le rapporteur. Les As a triager we should try to check the information that was originally reported by the bug reporter. Les choses à vérifier sont :

    • Product
    • Version
    • Platform

    As a triager we should try to check the information that was originally reported by the bug reporter. Things to check include:

    • Product
    • Version
    • Platform

    Ajouter un développeur à la liste de CC

    Cette étape doit être réalisée uniquement si vous êtes sure que c'est suffisemment important de mettre un développeur en CC. Si vous pensez qu'un bug est suffisemment sérieux pour qu'il doive appeler une attention particulière mais peut être pas assez pour être ajouté au MAB, alors vous devez demander des avis supplémentaires. Veuillez utiliser cette fonction avec attention, nous ne voulons pas que nos développeurs soient inondés de demandes concernant des bugs mineurs. Pour ajouter la personne, ajoutez simplement son nom à la liste des CC et ajoutez un commentaire dans le bug expliquant la raison pour laquelle vous avez ajouté la personne en CC. Le nom correct correspondant figure sur cette liste d'experts.

    This step should only be done if you're sure that it is important enough to CC a developer. If you think that a bug is serious enough that it deserves extra attention but maybe does not belong in the category of Most Annoying Bugs, then you should seek out an expert for additional input. Please try to use this with care as we don't want to inundate our expert developers with minor bug pings. To add the user simply add their name to the CC list and put a comment on the bug telling the developers why you've added them to the CC Anyway, the right names can be found in the list of experts.

    Ajouter un membre QA à la liste des CC

    Ceci n'est pratiquement pas utilisé, si vous pensez que c'est utile de vous ajouter vous-même ou un autre membre de la liste QA, n'hésitez pas à le faire. À nouveau, assurez-vous d'ajouter un commentaire si vous ajoutez quelqu'un d'autre, celui-ci s'irriter sinon de ne pas savoir de quoi il retourne.

    This mostly is not used but if you feel like adding yourself or another QA member to the list might be useful, feel free to do so. Again, please make sure to add a comment if you're adding someone else to the list, otherwise they might get irritated at not knowing what's going on.

    Interoperability testing

    If the requirement for testing is opening or saving a file with Microsoft Office and you don't have access to the software, you might make use of Office Web Viewer. It works with Word, Excel, PowerPoint and ODF documents. You need to upload the document somewhere and then add the URL to the end of this link:

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

    You can then click the Print button in the top menu and finally Open PDF to get access to a PDF rendering of the document. This will both allow you to see how the document looks like in the latest version of Microsoft Office and share the PDF in Bugzilla.

    Bugzilla attachment links work with the viewer.

    To conveniently use the live viewer in Firefox
    • Add a new bookmark
    • Set some Name
    • Set the URL to:
    https://view.officeapps.live.com/op/view.aspx?src=%s
    • Set a Keyword, such as lv, press OK.
    • Now you can use the bookmarks keyword plus a bugdoc URL in the URL bar to open the bugdoc in the Office live viewer:
    lv https://bugs.documentfoundation.org/attachment.cgi?id=180059

    Special Triage Notes for the QA Team

    Here are some notes for Advanced Triagers on the QA/Team. If you're new, don't worry about any of this!

    Bug reports that are difficult to triage or close

    Sometimes we need special software or hardware to reproduce a bug or we face some other difficulty that prevents us from investigating. For these cases we have:

    The collection uses the MediaWiki Bugzilla extension, which pulls data from meta reports and various other queries.

    Extensions

    It is best to get the creator of the extension involved in triaging. The responsibility for contacting the creator is on the bug reporter.

    Also read:

    Locale-related controversy

    Sometimes we are faced with hot topics related to locales. There might be a situation where a national standard for something differs from the actual practice. In these cases, it can be useful to direct the issue reporter to the Unicode Common Locale Data Repository and their survey tool.

    Suggested Triage Order

    The tables below represent a suggested order to approach triaging. The goal of QA is to confirm the worst bugs first.

    Table By Platform (OS)

    Description All Bugs Windows Linux macOS Comments
    Bugs Reporting Crashes CrasherAll CrasherWindows CrasherLinux CrashermacOS These are bugs that have "crash" or some similar word in the title of the bug. For crashers the severity should be set to Major/Critical depending on how many users will be affected. Also, QA should look at if the crash is a regression or not and add "regression" to keywords if the bug is determined to be a regression.
    Potential Regressions possibleRegressionAll possibleRegresionWindows possibleRegressionLinux possibleRegressionmacOS If the bug is confirmed to be a regression, the Keyword "possibleRegression" should be removed and "regression" should be added to the keywords.
    Keyword Regression RegressionAll RegressionWindows RegressionLinux RegressionmacOS The reporter of the bug or someone else has put regression in the keyword. Equally important as the row above but Bugzilla does not allow an "or" search so had to split into two rows.
    Bugs Reported as Critical CriticalAll CriticalWindows CriticalLinux CriticalmacOS Only contributors with special privileges can set bugs to critical. Critical is reserved for very serious bugs (such as data loss which will affect many userse). For guidance see PriorityFlowChart
    Bugs Reported as Major MajorAll MajorWindows MajorLinux MajormacOS Only contributors with special privileges can set bugs to major. Major is reserved for very serious bugs (such as data loss) but which will likely not affect many users or are only happening in corner cases with individual documents. For guidance see PriorityFlowChart.
    All Bugs AllBugs AllWindows AllLinux AllmacOS List of all bug reports (no enhancements). If the above bugs are tackled first then the ones remaining will be of slightly lower priority to confirm. Suggestion is to do these in chronological order (oldest first so that users who reported the longest time ago get priority).
    Enhancement Requests EnhancementAll EnhancementWindows EnhancementLinux EnhancementmacOS Enhancement requests are the lowest priority to confirm as valid requests.

    Table By Component

    Description Writer Calc Impress Draw Base Other Comment
    Bugs Reported as Crashers WriterCrasher SpreadsheetCrasher PresentationCrasher DrawingCrasher DatabaseCrasher OtherCrashers 'Critical' severity is reserved for only the most serious bugs (such as inability to install LibreOffice). For guidance see PriorityFlowChart
    Potential Regressions WriterPosReg SpreadsheetPosReg PresentationPosReg DrawingPosReg DatabasePosReg OtherPosReg If the bug is confirmed to be a regression, the Keyword "possibleRegression" should be removed and "regression" should be added.
    Keyword Regression WriterRegression SpreadsheetRegression PresentationRegression DrawingRegression DatabaseRegression OtherRegressions The reporter of the bug or someone else has put regression in the keyword. Equally important as the row above but Bugzilla does not allow an "or" search so had to split into two rows.
    Bugs Reported as Critical WriterCritical SpreadsheetCritical PresentationCritical DrawingCritical DatabaseCritical OtherCritical Only contributors with special privileges can set bugs to critical. Critical is reserved for very serious bugs (such as data loss which will affect many userse). For guidance see PriorityFlowChart.
    Bugs Reported as Major WriterMajor SpreadsheetMajor PresentationMajor DrawingMajor DatabaseMajor OtherMajor Only contributors with special privileges can set bugs to major. Major is reserved for very serious bugs (such as data loss) but which will likely not affect many users or are only happening in corner cases with individual documents. For guidance see PriorityFlowChart.
    All Other Bugs WriterOther SpreadsheetOther PresentationOther DrawingOther DatabaseOther AllOther These are all bugs marked as anything below Major but not including Enhancements.
    Enhancement Requests WriterEnhance SpreadsheetEnhance PresentationEnhance DrawingEnhance DatabaseEnhance OtherEnhance Enhancement Requests
    Retrieved from "https://wiki.documentfoundation.org/index.php?title=QA/BugTriage/fr&oldid=774311"