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 purpose of this document to assist anyone interested in helping improve Thunderbird through the process of triaging of Thunderbird bugs. The goal of triage is to either close a bug as no longer useful or invalid, or move it to a high state of quality - to a point where a developer can take action to fix it. Therefore triage, and your work, helps drive both the quality of the product and the development process, and ultimately impacts user satisfaction.

What's great about triage is anyone can help - technical skills are not required, nor is extensive experience required. And there are many people to help you with the product, with QA, and triaging.

In short, we need your help.

Contributing, aka How you can help with Thunderbird bugs

You can help, and we need you. You can:

  • 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. (Many bugs are unconfirmed (UNCO). And many "confirmed" bugs are of poor quality - for example very old and need to be evaluated again.)
  • If you don't have Bugzilla privileges (canconfirm/editbugs) we suggest you work towards getting privileges. You can do this as you comment in bugs and file new ones. Note: anyone can comment in bugs - privileges are optional and not needed to just comment.
  • 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 steps to to reproduce
  • Determine if a bug exists on a newer release, or trunk build
  • Confirm or resolve the bug if you have privileges

Things you can add to Status Whiteboard:

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

Triage Resources, Tools and Hints


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 ( 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 @, 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