Thunderbird:Bug Triage

From MozillaWiki
Jump to: navigation, search

<< Back to Thunderbird Testing

To be notified of changes to this page either [Login] and set a Watch, or use [Wiki RSS]

The document is a reference for anyone interested in helping improve Thunderbird through the process of triaging Thunderbird bug reports.

The goal of triage is to close a bug as no longer useful or not a valid bug, or move it to a high state of quality - to a point where the bug has enough information for a developer to take action to fix it.

What's great about triage is anyone can help - coding skills are not required, nor is extensive experience required. Being a user of Thunderbird is good enough. And we have people who can help you. Your triage work can impact both the quality of the product and the speed of development process, and ultimately improve user satisfaction.

But this doesn't happen without volunteers. In short, we need your help.

Contributing, aka How you can help with Thunderbird bugs

Easy ways to get started:

  • cc: yourself on bugs you care about, or perhaps can help with in the future but can't help right now.
  • Triage and comment in existing bug reports to improve the quality, or to prove or disprove that the bug exists. (Primarily bug reports whose state is "unconfirmed/UNCO". Also, some old bug "confirmed" bugs are of poor quality and need retesting.)
  • If you don't have Bugzilla privileges (canconfirm/editbugs) we suggest you take steps to get privileges. A starting point is just adding good information to existing bug reports, or helping the bug reporter better define their bug. (anyone can comment in bugs - privileges not needed)
  • File a new bug if you see a problem that hasn't been reported.

Where to get help and places for discussion (for Testing and QA)

Triage Process

Work on the bug by yourself, or with others, to evaluate and/or improve the bug, and help drive it to a successful resolution.

From Thunderbird bugzilla queries or your own query, pick bugs that interest you or that you experience. If you don't have a specific interest, in #tb-qa we can suggest bugs that are deserving of interest and care.

Use the triage processes described in Confirm the unconfirmed and What to Do and Not. Especially:

  • Add or improve details steps to to reproduce.
  • Determine if a bug exists on a newer release, or daily build.
  • Confirm or resolve the bug if you have privileges.

Things you can add to Status Whiteboard:

  • [closeme YYYY-MM-DD] - if you directed a question or gave instructions to a bug reporter, pick a date 2-4 weeks in the future to allow time for a response (see Closemes)
  • [workaround comment ##] - to indicate useful instructions
  • [dupeme] - if you believe this is a duplicate of another bug, but don't know which one
  • [patchlove] - if a patch needs attention
  • [good first bug] - you think coding the solution will be simple, good for a first-timer bug query

Triage Resources, Tools and Hints

Closemes

The closeme list is a series of bugs with an expiry date on them. On or around the expiry date, action will be taken to resolve that bug, which could come as either being resolved incomplete (what happens when no one responds), removed from the list and added as qawanted bug, confirmed, or resolved to an appropriate status. Processing is done manually and typically (but not always) during the first session on bugdays by User:Jcranmer.

To add a bug to the closeme list, put "closeme yyyy-mm-dd" in the status whiteboard, where yyyy-mm-dd is the expiry date you wish to set, which should generally be 2-3 weeks from the current day. A request for information--most commonly "Is this reproducible in current builds?" or some variant--is also highly recommended. If someone later responds, it is recommended that you (the person who adds the bug) take action as warranted, typically resolving "worksforme" in the most common case.

The list can be found as a shared query. That list only tracks bugs in the Thunderbird and MailNews Core components; a second list tracks bugs in four Core: Networking components that are mailnews-related.

Canconfirm and Editbugs Privileges

Check your bmo (bugzilla.mozilla.org) privileges (Requires log-in) Do you see canconfirm or editbugs?

Getting elevated privileges, so you can more easily change or triage Thunderbird bugs, is simple - mail a few bug numbers (3-6 is fine) of your best bug reports and best comments in other people's bugs (do not a list of all your bugs - please do not email a bug query), which demonstrate your best work to vseerror @ lehigh.edu, or catch someone in #maildev on IRC. You want to show that you understand how to help other people, analyze the information in the bug, and potentially to use the privileges being requested. If everything looks good (and it normally does) then you'll quickly get elevated privileges. You can ask for ...

  • "canconfirm" allows you to create bugs in a New state, and to confirm other people's bugs by changing them from UNCO to NEW. To get this privilege cite any of the following:
    • good bug reports you have filed
    • If you haven't filed many bugs, go through the steps under "Confirm the Unconfirmed" for three bugs.
  • "editbugs" (higher than and given more frequently than canconfirm) allows you to edit most aspects of any bug. Cite "canconfirm" examples listed above, plus ...
    • The URLs of three bugs where you wanted to change the resolution or fields in the bug but couldn't, and so you added a comment instead.
    • (optional) The URLs of two bugs to which you have attached patches or testcases.

For more info about bugs, testing and triage see Thunderbird:Testing