Thunderbird:Bug Triage: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Flesh out resources, Add watch info)
(→‎Triage Resources, Tools and Hints: Update The Bug Writing Guidelines & What not to do bzla)
 
(49 intermediate revisions by 7 users not shown)
Line 1: Line 1:
<small>[[Thunderbird:Testing|<< Back to Thunderbird Testing]]</small>
<small>[[Thunderbird:Testing|<< Back to Thunderbird Testing]]</small>


''This document changes frequently. To be notified of changes either [[http://wiki.mozilla.org/index.php?title=Special:Userlogin Login]] and set a '''Watch''', or use [[http://wiki.mozilla.org/index.php?title=Special:Recentchanges&feed=rss Wiki RSS]]''
''To be notified of changes to this page either [[https://wiki.mozilla.org/index.php?title=Special:Userlogin Login]] and set a '''Watch''', or use [[https://wiki.mozilla.org/index.php?title=Special:Recentchanges&feed=rss 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 and resolution of bugs helps drive both the quality of the product and the development process, and thus 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 where a developer can take action to fix and resolve it.
The reference is for anyone interested in helping improve Thunderbird by triaging Thunderbird bug reports.  


What's great is anyone can help, no matter how little or how extensive your experience with the product, with QA, with code, or with triaging. And there are plenty of people to help you in this process. No prior experience is needed.
'''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.'''


The current state of Thunderbird bugs is mixed, so we can use your help. Many are actively being worked on by developers or are of high enough quality for any coder to pick up the bug and work on itBut, there are many unconfirmed (UNCO) bugs and bugs of poor quality - in a confirmed state but very old and in need of reevaluation.
<u>What's great about triage is anyone can help</u> - coding skills are not required, nor is extensive experience required. Being a user of Thunderbird is good enough.   


=== Contributing, aka How you can help with Thunderbird bugs ===
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.


In general:
<u>But this doesn't happen without volunteers.  In short, we need your help.</u>


* Don't have elevated Bugzilla privileges canconfirm or editbugs? (if you don't know what these are then you don't have them) Then we suggest as you comment in bugs and file new ones, that you work toward getting your privileges. See [[Canconfirm and Editbugs Privileges| simple instructions]] on how to get these privileges.  (Note: privileges not needed to just comment in bugs.)
== Contributing, aka How you can help with Thunderbird bugs ==


* [[Thunderbird:Bug_Triage#Triage Process|Triage and comment in]] existing bug reports to either improve the quality or to prove or disprove that the bug exists. [[#Triage Process|x]]
Easy ways to get started (bugzila account is needed):


* cc: yourself (without comment) on bugs you care about or can help in the future but can't help just now.
* cc: yourself on bugs you care about - click '''Follow''' at the top of a bug report.


* File a new bug if you have a problem that hasn't been reported, or an existing bug report mentions more than one problem that do not have a bug filed.
* [[Thunderbird:Bug_Triage#Triage Process|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.


* Help with [[Thunderbird:Testing|Testing and QA of future versions and updates]]
* If you don't have Bugzilla privileges (canconfirm/editbugs) we suggest you [[#Canconfirm and Editbugs Privileges|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)


* Help with Thunderbird Bug Days
* File a new bug if you see a problem that hasn't been reported.


=== Triage Process ===
* Help with [[Thunderbird:Testing|Testing and QA of future versions and updates]].


From canned the [[Thunderbird:Bug_Queries|Thunderbird bugzilla queries]], or your own query, pick the type of bugs you are interested in or presently have trouble with.  If you don't have a specific interest, we provide bugs that are deserving of interest and care.
* Help with and have fun in [[Thunderbird:Bugdays|Thunderbird Bug Days]].


Then, use the well established triage process, working by yourself or in tandem with the reporter and others in the bug, to evaluate and/or improve the bug, and help drive it to a successful resolution.
* More opportunities at [https://www.thunderbird.net/en-US/get-involved/ Get Involved].


Especially:
== Where to get help and places for discussion (for Testing and QA) ==
* Add or improve steps to to reproduce
* [[Thunderbird:Bugdays#Where|Matrix room chat]] - help with QA/triage tools and methods: #qa channel -- product-related help: [https://matrix.to/#/#maildev:mozilla.org #Thunderbird Developers]
* Determine if a bug exists on a newer release, or trunk build
* [https://thunderbird.topicbox.com/groups/beta Beta topic]
* Confirm or resolve the bug if you have [[Bug_Triage#Canconfirm and Editbugs Privileges|privileges]]
* [https://thunderbird.topicbox.com/groups/daily Daily development builds topic]


=== Triage Resources, Tools and Hints ===
== 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:Bug_Queries|Thunderbird bugzilla queries]] or [https://bugzilla.mozilla.org/query.cgi? your own query], pick bugs that  interest you or that you experience. If you don't have a specific interest, in [https://matrix.to/#/#maildev:mozilla.org #Thunderbird Developers] we can suggest bugs that are deserving of interest and care.
 
Use the triage processes described in [https://developer.mozilla.org/en/Confirming_unconfirmed_bugs Confirm the unconfirmed] and [https://developer.mozilla.org/en/What_to_do_and_what_not_to_do_in_Bugzilla 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 [[#Canconfirm and Editbugs Privileges|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|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
* [[Thunderbird:PatchLove|[patchlove]]] - if a patch needs attention
* [good first bug] - you think coding the solution will be simple, good for a first-timer [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=anywordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=good+first+bug&keywords_type=allwords&keywords=&product=MailNews+Core&product=Thunderbird&emailreporter1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0= bug query]
 
== Triage Resources, Tools and Hints ==


* Builds
* Builds
** [[http://update-watch.localgho.st/nightly/production/latest/ Hourly builds]] - to test a patch that a developer '''just''' landed
** <!-- treeherder builds somewhere [https://update-watch.localgho.st/nightly/production/latest/ Hourly Trunk builds] - to test a patch that a developer '''just''' landed -->
** [[ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-trunk/ Nightly builds aka nightlies]] - the bleeding edge
** [https://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-central-l10n/ Nightly Trunk builds aka nightlies] - the bleeding edge (Trunk, is the main branch of the continuous Thunderbird development)
** [[ftp://ftp.mozilla.org/pub/thunderbird/releases/ Archives of Branch Releases]]
** [https://ftp.mozilla.org/pub/thunderbird/releases/ Branch Releases, Archive]
** [[http://forums.mozillazine.org/viewtopic.php?t=388559 An explanation about versions and builds for testing...]]
** [http://forums.mozillazine.org/viewtopic.php?t=388559 An explanation about versions and builds for testing...]
** see also builds forum below
** see also builds forum below
* bugzilla
* [https://bugzilla.mozilla.org/ Bugzilla]
** [[http://developer.mozilla.org/en/docs/What_to_do_and_what_not_to_do_in_Bugzilla What and what not to do in Bugzilla]]
** Search Shortcuts:
** bookmark shortcuts
*** [https://bugzilla.mozilla.org/ "Install the (FF) Quick Search plugin"]
* Crash reports for [[http://talkback.mozilla.org/ branch builds @talkback]], [http://crash-stats.mozilla.com trunk builds @crash-stats]]  (note: NTT extension provides direct links to ''your'' crashes)
*** [https://bugzilla.mozilla.org/page.cgi?id=quicksearchhack.html "Find a bug" help] for not well-known & underappreciated '''quick search''' 
* extensions useful in debugging and/or triage
** [https://bugzilla.mozilla.org/query.cgi Search Advanced]
** thunderbird: [[https://addons.mozilla.org/en-US/firefox/addon/6543 Nightly Tester Tools aka NTT]], [[https://nic-nac-project.de/~kaosmos/index-en.html#profname Profile Switcher]]
** [https://developer.mozilla.org/en/docs/What_to_do_and_what_not_to_do_in_Bugzilla What and what not to do in Bugzilla] (Link Broken)
** firefox: [[https://addons.mozilla.org/en-US/firefox/addon/6543 Nightly Tester Tools aka NTT]], [[https://addons.mozilla.org/en-US/firefox/addon/126 TinyURL Creator]], [[https://addons.mozilla.org/en-US/firefox/addon/748 greasemonkey]]
** [https://bugzilla.mozilla.org/page.cgi?id=bug-writing.html The Bug Writing Guidelines]
*** greasemonkey scripts
* [[Thunderbird:Debugging|Useful Extra Debugging]] for expanding bug reports.
* Discussion and Help (for Testing and QA)
* Extensions useful in debugging, using bugzilla and triage
** [news://news.mozilla.org:119/mozilla.dev.apps.thunderbird mozilla.dev.apps.thunderbird newsgroup]  
** firefox:  
** [[irc://irc.mozilla.org/ IRC chat]] -- general QA help: #qa channel -- mail developers: #maildev channel
 
** [[http://weblogs.mozillazine.org/rumblingedge/ Weekly developments in Mozilla Thunderbird builds]]
* References and Miscellaneous
** [[http://forums.mozillazine.org/viewtopic.php?p=3292444#3292444 Daily Build Thread]], and in [[http://th3oretiker.de/stuff/thunderbirdfeed.xml RSS]]
** [http://kb.mozillazine.org/General_concepts Mozilla General Concepts and Terms]
** [[http://forums.mozillazine.org/viewforum.php?f=29 Builds Forum]] - The testing community at Mozillazine
** Excellent [https://developer.mozilla.org/en/docs/Glossary Glossary]
* News and Archival Information
** [https://www.mozilla.org/quality/help/bugzilla-privilege-guide.html#unconfirmed https://www.mozilla.org/quality/help/bugzilla-privilege-guide.html#unconfirmed]
** [[http://wiki.mozilla.org/Releases Releases Tracking]] - schedule, plan and bugs fixed
** [http://weblogs.mozillazine.org/rumblingedge/archives/2005/06/thunderbird_release_changelogs.html Thunderbird Release Changelogs]]
* Miscellaneous
** Excellent [[http://developer.mozilla.org/en/docs/Glossary Glossary]]
** http://www.mozilla.org/quality/help/bugzilla-privilege-guide.html#unconfirmed


=== Canconfirm and Editbugs Privileges ===
==== 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 get elevated privileges to triage '''Thunderbird''' bugs ...
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.


If you don't have canconfirm privilege (which allows you to create bugs in a New state and confirm other's bugs by changing them from Unco to New) do one of the following:
The list can be found [https://bugzilla.mozilla.org/buglist.cgi?cmdtype=runnamed&namedcmd=Thunderbird%20closeme 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.
* If you haven't filed many bugs, go through all the steps under [http://www.mozilla.org/quality/help/unconfirmed.htm|"Confirm the Unconfirmed"] for three bugs.
* [[Mail]] the full URLs of the bugs.
* If everything looks okay, you'll then get the "can confirm a bug" privilege.


To get "editbugs", allows you to edit most aspects of a bug, [[mail]] either:
== Canconfirm and Editbugs Privileges ==
* The URLs of two bugs to which you have attached patches or testcases; or
* The URLs of the relevant comment on three bugs which you wanted to change, but couldn't, and so added a comment instead.


Bugs you probably do not want to not use towards getting your privileges :
[https://bugzilla.mozilla.org/userprefs.cgi?tab=permissions 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 [https://www.mozilla.org/quality/help/unconfirmed.html "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]]
<!-- Bugs you may not want to not use towards getting your privileges :
* CLOSEME in whiteboard - many are trivial and/or lack much useful information
* CLOSEME in whiteboard - many are trivial and/or lack much useful information
* Bugs about moving and copying messages - often not easily verified (Exception: if you personally experienced the problem in the time frame described by the reporter(s), and therefore in a good position to say whether the problem does or does not exist today on a newer release.)
* Bugs about moving and copying messages - often not easily verified (Exception: if you personally experienced the problem in the time frame described by the reporter(s), and therefore in a good position to say whether the problem does or does not exist today on a newer release.) -->
 
See / add useful information


[[category:Thunderbird|*]]
[[category:Thunderbird|*]]

Latest revision as of 11:06, 9 March 2023

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