Bug triage 101
Imported from https://lists.dulug.duke.edu/pipermail/fedora-triage-list/2004-January/000002.html
This is a short guide based on what I've done in the past with the various 'blocker' and 'target' lists for various Red Hat Linux/Fedora Core releases. It is not the end-all and be-all of bug triage; it's not even close. The idea here is to do a good pass on the bugs, in a minimum amount of time. Mainly because I always had other things to do.
What was done was:
1) go through all newly opened bugs for Fedora Core, and Red Hat Raw Hide. You can tweak the versions so you don't get old FC bugs.
2) assign bugs to our blocker lists of 'blocker' and 'target' bugs, based on a somewhat vague policy in my head
3) mark bugs as duplicates when necessary (and when it's obvious)
4) assign misfiled bugs to proper components
5) prod reporters once for more information if it's obvious that there's some missing
6) post summaries occasionally on the status of blocker and target bugs (what % are fixed, what % need verification of fixes)
What wasn't done was:
7) perform followup triage on new information
8) gather statistics, etc.
9) individually nag developers aside from occasionally posting the huge blocker lists
10) try and reproduce/make test cases, etc.
11) go through new bugs once actually released.
These things all require more time. In the case of #7, it's most efficient if you're CC'd on all the bug changes too, and that's a lot of mail.
'Blocker' and 'Target' are really just two levels of priority.
Not every bug is classified as one of these two. Some people disagree with this, and state that every bug should be either
- resolved as invalid
- targeted at a specific upcoming release
- pushed upstream.
I.e., if it's not on one of the lists, it ends up closed. This doesn't really handle the case for where this bugzilla *is* the upstream bugzilla for the project. (For example, anaconda.)
The criteria I've been using for blocker/target is something along the lines of:
Blocker bugs include: - crash on program startup/failure to startup - crash during the most-used portions of a program - complete failure to do the programs main function (e.g.: evolution can't send mail.) - installer tracebacks/crashes - configuration tool tracebacks/crashes - kernel oops/hang - kernel file/memory corruption - X driver failures for an entire range of hardware - incorrect licensing information in the spec file - failure of a package to rebuild in our build environment (*) - non-functional translations in one of our tier-1 languages - errors on package install - other packaging errors of various sorts (missing files, bad dependencies, etc.)
(*) only a blocker for the final release, never for a beta
Target bugs include: - a little more vague. Anything that you look at and think 'we should fix that'. - other crashes - typos in dialogs, etc.
Of course, the same bug can go from being a blocker to being a target the closer we get to release. Morever, I tend to be more likely to make a bug target/blocker if it's on stuff we write in house.
[[Category:Bugs