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.
- Help with Testing and QA of future versions and updates
- Help with and have fun in Thunderbird Bug Days
- More info and opportunities at Mozilla Messaging - Get Involved
Where to get help and places for discussion (for Testing and QA)
- IRC chat - help with QA/triage tools and methods: #qa channel -- product-related help: #maildev
- mozilla.dev.apps.thunderbird newsgroup
- Weekly developments in Mozilla Thunderbird builds
- Daily Build Thread, and in RSS
- Builds Forum - The testing community at Mozillazine
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.
- 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
- Builds (Trunk=Thunderbird 3)
- Hourly Trunk builds - to test a patch that a developer just landed
- Nightly Trunk builds aka nightlies - the bleeding edge
- Branch Releases, Archive
- An explanation about versions and builds for testing...
- see also builds forum below
- Useful Extra Debugging for expanding bug reports.
- Extensions useful in debugging, using bugzilla and triage
- tab kit more powerful tabbing for bug triage - tabs colored by age/visitation; more visible active tab; when tabs moved to side of window are shown as nested/indented to depict how they were opened (i.e. parent/child); opens tabs in a more logical location; when a tab is closed better selection of the active next tab; optional grouping controls; tons of options; stable!
- Nightly Tester Tools aka NTT, TinyURL Creator, greasemonkey
- greasemonkey scripts:
- thunderbird: Nightly Tester Tools aka NTT, Profile Switcher
- Crash reports for branch builds @talkback, trunk builds @crash-stats (note: NTT extension provides direct links to your crashes)
- News and Archival Information
- References and Miscellaneous
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