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