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. 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 at Mozilla Messaging - Get Involved

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

• 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)

Getting elevated privileges, so you can more easily triage Thunderbird bugs, is simple. What you supply will demonstrate that you have enough background to work with privileges. Simply mail a sampling your best bugs and bug comments - the full URLs - which demonstrate your abilities to vseerror @ lehigh.edu, or catch someone in #maildev on IRC. (please do not email a bug query) 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 the relevant comments on 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