User:Johannbg/QA-community/BugTriage

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?