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 reference is for anyone interested in helping improve Thunderbird by 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 - such that 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 (bugzila account is needed):

  • cc: yourself on bugs you care about - click Follow at the top of a bug report.
  • Triage and comment in an "unconfirmed/UNCO bug report to improve the quality, or to prove or disprove that the bug exists. Also, some old bug "confirmed" bugs are of poor quality and need retesting. Asking the reporter to do some of the leg work is also a productive approach.
  • 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 #Thunderbird Developers 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 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
  • tag a bug comment as workaround, metoo, str, or important
  • [STR comment ##] - to indicate better instructions to reproduce the bug that aren't in comment #0
  • [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 bugs with an expiry date on them. After the expiry date, action will be taken to resolve a bug, perhaps incomplete (when no one responds), confirmed, or resolved. This clean up process is done manually.

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 2-3 weeks from the current date. 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

Retrieved from "https://wiki.mozilla.org/index.php?title=Thunderbird:Bug_Triage&oldid=1245735"