Thunderbird:Bug Triage

<< 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. Triage of bugs and their resolution helps drive both the quality of the product and the development process. Therefore, triage has a great impact on user satisfaction. The goal of triage is to either close the 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.

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

In short, we need your help. Many bugs are unconfirmed (UNCO). And many "confirmed" bugs are of poor quality - for example very old and need to be evaluated again.

Contributing, aka How you can help with Thunderbird bugs

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

• cc: yourself (with or without comment) on bugs you care about, or 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.

• 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: any one can comment in bugs - privileges are optional and not needed to just comment.

• File a new bug if you have a problem that hasn't been reported, or an existing bug report mentions a problem that does not yet have a bug filed.

• Help with Testing and QA of future versions and updates

• Help with and have fun in Thunderbird Bug Days

• Mozilla Messaging - Get Involved

Triage Process

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

From canned Thunderbird bugzilla queries or your own query, pick bugs you are interested in or presently have trouble with. If you don't have a specific interest, we can suggest bugs that are deserving of interest and care.

Use 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
• closeme YYYY-MM-DD - choose 2-4 weeks in the future
• workaround comment ##
• [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
• Bugzilla
  • Search Shortcuts:
    • "Install the (FF) Quick Search plugin"
    • "Find a bug" help for not well-known & underappreciated quick search
  • Search Advanced
  • What and what not to do in Bugzilla
• Useful Extra Debugging for expanding bug reports.
• Extensions useful in debugging, using bugzilla and triage
  • firefox:
    • 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:
      • Highlight Table Row on Click to mark your place
      • Ruderman's Bookmarklet Bugzilla collection including "shorten bug query", "hide visited bug rows", "reference bug", "prefill bug report"
  • 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)
• Discussion and Help (for Testing and QA)
  • mozilla.dev.apps.thunderbird newsgroup
  • IRC chat -- help with QA/triage tools and methods: #qa channel -- product-related help: #maildev
  • Weekly developments in Mozilla Thunderbird builds
  • Daily Build Thread, and in RSS
  • Builds Forum - The testing community at Mozillazine
• News and Archival Information
  • Releases Tracking - schedule, plan and bugs fixed
  • Thunderbird Release Changelogs
• References and Miscellaneous
  • Mozilla General Concepts and Terms
  • Excellent Glossary
  • http://www.mozilla.org/quality/help/bugzilla-privilege-guide.html#unconfirmed

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 bugzilla.mozilla.org privileges (Requires log-in)

The process to get elevated privileges, so you can easily triage Thunderbird bugs, is simple and is designed to demonstrate that you can be trusted with the privileges. Simply mail the full URLs of bugs which demonstrate your abilities to vseerror @ lehigh.edu, or catch someone in #maildev on IRC. If everything looks good (and it normally does) then you'll quickly get elevated privileges. You can ask for one of these types ...

• "canconfirm" allows you to create bugs in a New state, and 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", given more frequently, allows you to edit most aspects of any bug. Supporting examples you can cite include the "canconfirm" examples listed above, plus ...
  • The URLs of the relevant comments on three bugs which you wanted to change, but couldn't, and so you added a comment instead.
  • The URLs of two bugs to which you have attached patches or testcases