QA/BugTriage: Difference between revisions
Appearance
< QA
removed now obsolete old unconfirmed bugzilla query |
|||
| Line 22: | Line 22: | ||
#* do not spend ages on it; do it if it affects an often used functionality or if it triggers a bell | #* do not spend ages on it; do it if it affects an often used functionality or if it triggers a bell | ||
#Check that it has all the [[BugReport|required information]]. If not, ask for the information: | #Check that it has all the [[BugReport|required information]]. If not, ask for the information: | ||
#* | #*Assign the bug to the one who needs to provide the information and set bug status to "NEEDINFO". | ||
#Try to reproduce the issue, according to the instructions. If you are not successful, back to the previous step - ask for more info :-) | #Try to reproduce the issue, according to the instructions. If you are not successful, back to the previous step - ask for more info :-) | ||
#When the infoprovider fills in the information, he should reset the Whiteboard/Keywords; but that could be reset by the person doing the bug triage once the required information is available too. | #When the infoprovider fills in the information, he should reset the Whiteboard/Keywords; but that could be reset by the person doing the bug triage once the required information is available too. | ||
Revision as of 23:59, 23 December 2011
TDF LibreOffice Document Liberation Project Community Blogs Weblate Nextcloud Redmine Ask LibreOffice Donate
Introduction
This document provides information for processing bugs on the Bugzilla for LibreOffice.
Details on How to report LibreOffice Bugs are also available.
Process
Generally the following steps would be followed:
- Query for new bugs assigned to libreoffice-bugs@lists.freedesktop.org
- Search for duplicates:
- if there is another bug describing the same problem, add a comment and set the status to "RESOLVED DUPLICATE"
- do not spend ages on it; do it if it affects an often used functionality or if it triggers a bell
- Check that it has all the required information. If not, ask for the information:
- Assign the bug to the one who needs to provide the information and set bug status to "NEEDINFO".
- Try to reproduce the issue, according to the instructions. If you are not successful, back to the previous step - ask for more info :-)
- When the infoprovider fills in the information, he should reset the Whiteboard/Keywords; but that could be reset by the person doing the bug triage once the required information is available too.
- After the issue is reproduced - Add CONFIRMED to the Whiteboard and a comment saying so.
- If its higher priority issue (broken parts, regression, etc), assign it to one of the developers listed on the Find The Experts page
- English is encouraged for opening a bug. If the bug is not reported in English, please assign it to our 'non-English bug description' expert in the Find The Experts page so that we can help find warmhearted people to translate it to English.
- If you think it is a candidate for Easy Hacks, please do add it there. And add the "ProposedEasyHack" word to the Whiteboard of the bug (add "EasyHack" if you are a developer and competent in making that judgement).
- When you know a developer working on that specific area, change the Assigned to field accordingly. However, the field Status, should stay NEW. If the specific developer or one of her/his coworkers accepts the issue to work on, s/he will change that to ASSIGNED. (See this mail on the QA list.