From Fedora Project Wiki
 
(8 intermediate revisions by the same user not shown)
Line 2: Line 2:


This document provides information on how to triage bugs for the Fedora project. Triaging is the name given for confirming, prioritizing, and organizing bug reports and is a good place for new contributors and/or contributors with limited programming abilities to help the Fedora project becoming a better distribution for everyone. Triaging is an incredibly important aspect of development that benefits users and developers alike by acting as a bridge between users and developers to aid in fixing and closing bugs.
This document provides information on how to triage bugs for the Fedora project. Triaging is the name given for confirming, prioritizing, and organizing bug reports and is a good place for new contributors and/or contributors with limited programming abilities to help the Fedora project becoming a better distribution for everyone. Triaging is an incredibly important aspect of development that benefits users and developers alike by acting as a bridge between users and developers to aid in fixing and closing bugs.
== Why Triage Bugs? ==
* The less time package maintainers have to spend resolving duplicates, attempting to reproduce bugs, and requesting missing information, the more time they can spend fixing bugs.
* Helps to identify bugs that should be fixed before release (adding to tracker and blocker lists)
* Gives bug reporters the feeling that someone has acknowledged their problem
* Strives to provide a level of certainty that the total number of open bugs is accurate
* Closing bugs for EOL releases helps keep Bugzilla tidy and useful, and lets reporters know they need to upgrade
* Identifying workarounds can help users in the meantime until a bug is fixed
* Provides an idea of where problem areas are in the distribution
* Good way to learn more about Fedora


== Steps to Triage a Bug ==
== Steps to Triage a Bug ==
Line 7: Line 18:
This section lists the steps necessary in order to triage correctly. This guide aims to be concise, links in some sections will provide more information relevant to the particular step. The triage process can be essentially broken up into four parts, the first being "preparation" the second being "reproducing" the third being "prioritization" and the fourth being "upstreaming".
This section lists the steps necessary in order to triage correctly. This guide aims to be concise, links in some sections will provide more information relevant to the particular step. The triage process can be essentially broken up into four parts, the first being "preparation" the second being "reproducing" the third being "prioritization" and the fourth being "upstreaming".


=== Summary of Steps of the steps involved ===
=== Summary of the steps involved ===


* Find Bugs to Triage
* Find Bugs to Triage
Line 18: Line 29:
* Upstream reports
* Upstream reports


== Details of each step ===
=== Details of each step ===


Preparation
Preparation


In general you'll always want to do the following steps in preparing to triage bugs.
In general you'll always want to do the following steps in preparing to triage bugs.
=== Step 1. Find Bugs to Triage ===
a) Bugzilla Search
Navigate to Fedora bug tracker system available at bugzilla.redhat.com  After logging in, browse open issues by component or do a custom search for bugs that are:
a) filed in Fedora product
b) have NEW,UNCONFIRMED or REOPENED status
c) add whatever other criteria you'd like to query for
Once you are there, search for a bug that you'd like to triage. Custom search for bugs can be build using the Advanced Search form or entering search terms in the Quick Search field (Bugzilla Quick Search help).
Please do not touch bugs with a product that is not "Fedora" (especially Red Hat Enterprise Linux bugs).
Please do not triage bugs filed against the "Package Review" component, which usually have "Merge review" in the summary.
=== Step 2. Search for Duplicates ===
Duplicates are bugs marked RESOLVED DUPLICATE which are very similar or identical but reported by different users. Such bugs are automatically counted by Bugzilla and available at Most Frequently Reported Bugs page. When triaging please check that list and do a quick search through bugs in Bugzilla to see if there are any duplicates of the bug that you have, but don't need to spend a lifetime on this. As you see more bugs you may remember seeing a similar bug and can easily close the newest of the two (or more) bugs. In general minimizing the amount of duplicate bugs entered into Bugzilla will save time everybody involved.
=== Step 3. Check Information ===
Checking information is critical for development. What you should look for is the following:
* Clear and meaningful summary
* Clear problem description
* Steps to reproduce the problem -- if not clear from summary and/or description
* Attachments -- in many cases attachments are needed to reproduce the problem, if attachment(s) are not provided this can hinder proper fixes
If all information is not properly there, skip to step #5
=== Step 4. Attempt to Reproduce ===
If the bug "passed" the Preparation steps it's time to try to reproduce the bug.
Do just that: Go through the steps necessary and try to reproduce the bug, that simple!
When you reproduce it, keep these things in mind:
* Did the bug reporter leave enough information in Bugzilla itself to reproduce the bug, or did you have to take extra steps? If extra steps were needed, add a comment to describe the extra step(s).
* Did your reproduction lead to the same result, something similar but not identical, or did everything work flawlessly?
=== Step 5. Set Status ===
This section is the last "mandatory" step of a successful triage and can only be done once steps #1–#4 are done (or #3 if #4 isn't applicable).
The STATUS of the bug is dependent on your results from the above steps. Below is a short description of the usage of each status.
* NEW: Confirmed bug, all information necessary is there
* NEEDINFO: All information needed to attempt replication is not included in the bug report. Please ask a particular person for a particular information in a comment.
* RESOLVED: This category comes with several options, if you can't replicate the bug, RESOLVED WORKSFORME is the appropriate STATUS, see HERE for more information.
* VERIFIED: This option is only available when the current bug status is RESOLVED. You can mark a RESOLVED FIXED bug as VERIFIED, when you can confirm it is fixed with the version mentioned in the bug report. It is also pleasant for the developer who fixed the issue, and is a confirmation the problem is solved now. Otherwise a bug reporter can mark their own bug that is in RESOLVED WORKSFORME state as VERIFIED WORKSFORME to verify it is somehow fixed.
* INVALID: There are many reasons why a bug can be determined to be invalid, but this usually requires input from other QA members. If you come across a bug that you believe to be invalid, best bet is to get a second opinion from the QA IRC channel or send an email out to the mailing list explaining why you believe the bug to be invalid.
* UNCONFIRMED: This is the status given to all new bugs that have not gone through triage process. Note that such bug might be also in NEEDINFO state.
ANY time you make changes you should put a comment that politely explains why you made the change or use the sample stock answers provided here #TODO ADD LINK

Latest revision as of 15:09, 26 January 2014

Introduction

This document provides information on how to triage bugs for the Fedora project. Triaging is the name given for confirming, prioritizing, and organizing bug reports and is a good place for new contributors and/or contributors with limited programming abilities to help the Fedora project becoming a better distribution for everyone. Triaging is an incredibly important aspect of development that benefits users and developers alike by acting as a bridge between users and developers to aid in fixing and closing bugs.

Why Triage Bugs?

  • The less time package maintainers have to spend resolving duplicates, attempting to reproduce bugs, and requesting missing information, the more time they can spend fixing bugs.
  • Helps to identify bugs that should be fixed before release (adding to tracker and blocker lists)
  • Gives bug reporters the feeling that someone has acknowledged their problem
  • Strives to provide a level of certainty that the total number of open bugs is accurate
  • Closing bugs for EOL releases helps keep Bugzilla tidy and useful, and lets reporters know they need to upgrade
  • Identifying workarounds can help users in the meantime until a bug is fixed
  • Provides an idea of where problem areas are in the distribution
  • Good way to learn more about Fedora

Steps to Triage a Bug

This section lists the steps necessary in order to triage correctly. This guide aims to be concise, links in some sections will provide more information relevant to the particular step. The triage process can be essentially broken up into four parts, the first being "preparation" the second being "reproducing" the third being "prioritization" and the fourth being "upstreaming".

Summary of the steps involved

  • Find Bugs to Triage
  • Search for Duplicates of Bug(s)
  • Check Information Provided in Bug Report
  • Attempt to Reproduce Bug
  • Set Bug Status
  • Prioritize Bug
  • Notify Developers -- Needed only in very specific cases if bug seems to be a Blocker/Critical.
  • Upstream reports

Details of each step

Preparation

In general you'll always want to do the following steps in preparing to triage bugs.

Step 1. Find Bugs to Triage

a) Bugzilla Search

Navigate to Fedora bug tracker system available at bugzilla.redhat.com After logging in, browse open issues by component or do a custom search for bugs that are:

a) filed in Fedora product

b) have NEW,UNCONFIRMED or REOPENED status

c) add whatever other criteria you'd like to query for

Once you are there, search for a bug that you'd like to triage. Custom search for bugs can be build using the Advanced Search form or entering search terms in the Quick Search field (Bugzilla Quick Search help).

Please do not touch bugs with a product that is not "Fedora" (especially Red Hat Enterprise Linux bugs).

Please do not triage bugs filed against the "Package Review" component, which usually have "Merge review" in the summary.

Step 2. Search for Duplicates

Duplicates are bugs marked RESOLVED DUPLICATE which are very similar or identical but reported by different users. Such bugs are automatically counted by Bugzilla and available at Most Frequently Reported Bugs page. When triaging please check that list and do a quick search through bugs in Bugzilla to see if there are any duplicates of the bug that you have, but don't need to spend a lifetime on this. As you see more bugs you may remember seeing a similar bug and can easily close the newest of the two (or more) bugs. In general minimizing the amount of duplicate bugs entered into Bugzilla will save time everybody involved.

Step 3. Check Information

Checking information is critical for development. What you should look for is the following:

  • Clear and meaningful summary
  • Clear problem description
  • Steps to reproduce the problem -- if not clear from summary and/or description
  • Attachments -- in many cases attachments are needed to reproduce the problem, if attachment(s) are not provided this can hinder proper fixes

If all information is not properly there, skip to step #5

Step 4. Attempt to Reproduce

If the bug "passed" the Preparation steps it's time to try to reproduce the bug.

Do just that: Go through the steps necessary and try to reproduce the bug, that simple! When you reproduce it, keep these things in mind:

  • Did the bug reporter leave enough information in Bugzilla itself to reproduce the bug, or did you have to take extra steps? If extra steps were needed, add a comment to describe the extra step(s).
  • Did your reproduction lead to the same result, something similar but not identical, or did everything work flawlessly?

Step 5. Set Status

This section is the last "mandatory" step of a successful triage and can only be done once steps #1–#4 are done (or #3 if #4 isn't applicable).

The STATUS of the bug is dependent on your results from the above steps. Below is a short description of the usage of each status.

  • NEW: Confirmed bug, all information necessary is there
  • NEEDINFO: All information needed to attempt replication is not included in the bug report. Please ask a particular person for a particular information in a comment.
  • RESOLVED: This category comes with several options, if you can't replicate the bug, RESOLVED WORKSFORME is the appropriate STATUS, see HERE for more information.
  • VERIFIED: This option is only available when the current bug status is RESOLVED. You can mark a RESOLVED FIXED bug as VERIFIED, when you can confirm it is fixed with the version mentioned in the bug report. It is also pleasant for the developer who fixed the issue, and is a confirmation the problem is solved now. Otherwise a bug reporter can mark their own bug that is in RESOLVED WORKSFORME state as VERIFIED WORKSFORME to verify it is somehow fixed.
  • INVALID: There are many reasons why a bug can be determined to be invalid, but this usually requires input from other QA members. If you come across a bug that you believe to be invalid, best bet is to get a second opinion from the QA IRC channel or send an email out to the mailing list explaining why you believe the bug to be invalid.
  • UNCONFIRMED: This is the status given to all new bugs that have not gone through triage process. Note that such bug might be also in NEEDINFO state.

ANY time you make changes you should put a comment that politely explains why you made the change or use the sample stock answers provided here #TODO ADD LINK