Jump to content

QA/BugTriage: Difference between revisions

From The Document Foundation Wiki
< QA
RBd (talk | contribs)
Bjoern-michaelsen (talk | contribs)
clarify that an enduser does not need to provide bibisects etc.
Line 29: Line 29:
#** the issue is '''''reproduced reliably''''' and  
#** the issue is '''''reproduced reliably''''' and  
#** you recognize the observed effect as a '''''real bug''''' and  
#** you recognize the observed effect as a '''''real bug''''' and  
#** you believe that now '''''all required information''''' the developer will need is in the comments
#** you believe that now '''''all required information an enduser can provide''''' (this includes for example a reproduction scenario, but not fancy tools like [[QA/HowToBibisect|bibisect]] that need special training) is in the comments
#: ''please remember to add a comment confirming the above criteria''
#: ''please remember to add a comment confirming the above criteria''
#* '''do not use Status ''NEW''''' if
#* '''do not use Status ''NEW''''' if

Revision as of 21:27, 15 August 2012

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:

  1. Query for new bugs assigned to libreoffice-bugs@lists.freedesktop.org
    • e.g. a listing UNCONFIRMED, REOPENED for the last two weeks by this query.
    • here a draft for a Link showing all Bugs still needing a review (still some fine tuning required).
  2. Dupes: 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
  3. 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". (This proceeding is under discussion on libreoffice-qa@lists.freedesktop.org. )
  4. Try to reproduce the issue, according to the instructions. If you are not successful, back to the previous step - ask for more info :-)
    • Please do not bother other users with "Try the latest Version" without having done an own test. If the proceeding is not too expensive do an own test and contribute your results. Only if a test is too difficult and/or there is an indication that the bug might have been fixed (not touched and/or reproduced in 2 major releases or similar) ask the reporter do to a new test.
  5. Update status:
    • to NEW if
      • the issue is reproduced reliably and
      • you recognize the observed effect as a real bug and
      • you believe that now all required information an enduser can provide (this includes for example a reproduction scenario, but not fancy tools like bibisect that need special training) is in the comments
    please remember to add a comment confirming the above criteria
    • do not use Status NEW if
      • you only were able to reproduce the effect, but are not sure whether you really see a bug or only an effect you do not understand (please see fdo#48970#c3 for example)
    • If its higher priority issue (broken parts, regression, etc), QA-team members and experienced users should preassign the Bug.
    • English is encouraged for opening a bug. If the bug is not reported in English, please add our 'non-English bug description' expert in the Find The Experts page to CC so that we can help find warmhearted people to translate it to English.
    • If you think it is a candidate for Easy Hacks, please add the "ProposedEasyHack" word to the Whiteboard of the bug (add "EasyHack" only if you are a developer and competent in making that judgement).
  6. If you know a developer working on that specific area, add him to the "CC" field accordingly. If the specific developer or one of her/his coworkers accepts the issue to work on, s/he will change Status to ASSIGNED and move his name to "Assigned to" field.

Useful links