Triggered by a question on The Old New Thing, I would like to ask:
How do you set up your bug tracker priorities? More generally, what are your rules for working on them? How strict are you with "fix bugs first"? All of them?
I've marked this community wiki, and I'll post mine as a separate answer. (So you can vote them down if you think they suck :)
I personally try to always work on bugs first, and then enhancements as a stable product is easier to implement enhancements in. Now it isn't a perfect world so that doesn't always happen, but that is my goal to reach.
At our place:
We use "fix for " and priorities (in that order) to give bugs and feature requests a recommended order of solving.
Our priorities are:
"Assign Priority" is highest and default for easy submittal. The least the developer responsible needs to do is assess severity, see if he can reproduce it, resolve duplicates etc.
Mostly, the developers are involved enough in their part of the products that they can figure out the order on their own, and he might fix a showstopepr before assessing a new case. Generally, I'd expect the respective manager to put these into a definite order in case of doubt - that's not the programmers job, but they are usually good at it.
We use FogBugz, btw.
Our prioritization system is always in the context of the current iteration of the software and works as follows.
As for the "fix bugs first" admonition. We generally do that, but also apply common sense to it. Not all bugs are created equally. If the system badly formats dates badly when they are past the year 10,000 it is certainly not critical to push back features to get that fix in. If it miscalculates someone's bank balance, well that gets to the top of the list.
I have no fault with the answers so far, but would like to add an observation concerning productivity. If a programmer is going into a subsystem to fix a bug, there is some time and effort spent getting reacquainted with the code. Therefore, fix every bug you can that appears to be coming from that subsystem. Use good judgment as to which subsystem to work on first, and when to move onto the next priority subsystem. This judgment is certainly influenced by what customer support thinks, and how others have classified bugs, but efficiency is also very important.
I believe My life as a Code Economist by Eric Sink belongs here. Its essence is: prioritize bugs according to severity, frequency, cost and risk. Do not fix every bug, but rather have a list of the less severe ones and fix them as you go along.
Apropos "Fix bugs first", we found that our customers push us a lot for quick fixes (which destabilise the system) and we couldn't push back so we ended up deciding on a "smoke" system. Any quick fix (ie. not properly reviewed or tested - just pushed out to satisfy a customer) counts as a "smoke" bug. If the number of open smoke bugs increased to above 5, we would clamp down and start a reduction drive. Also, we made a public announcement that we would not do quick fixes once this happened and involved our customers with the entire process.
Not exactly answering your question but the approach proved useful to us.
We use something like this (in practice the meanings are a bit fuzzier):
1. Blocker - Reserved for catastrophic failures - exceptions, crashes, corrupt data, etc. that (a) prevent somebody from completing their task, and (b) have no workaround. These should be extremely rare. They must be fixed immediately (same-day) and deployed as hotfixes.
2. Critical - These may refer to unhandled exceptions or to other "serious" bugs that only happen under certain specific conditions (i.e. a practical workaround is available). No hard limit for resolution time, but should be fixed within the week (hotfix) and must be fixed by next release. They key distinction between (1) and (2) is not the severity or impact but the existence of a workaround.
3. Major - Usually reserved for perf issues. Anything that seriously hampers productivity but doesn't actually prevent work from being done. Fix by next release.
4. Minor - These are "nuisance" bugs. A default setting not being applied, a read-only field showing as editable (or vice-versa), a race condition in the UI, a misleading error message, etc. Fix for this release if there are no higher-priority issues, otherwise the following release.
5. Minor - Cosmetic issues. Scroll bars appearing where they shouldn't, window doesn't remember saved size/location, typos, last character of a label being cut off, that sort of thing. They'll get fixed if the fix only takes a few minutes and somebody's working on the same screen/feature at the same time, otherwise, maybe never. No guarantee is attached to these.
2. Design Errors - As in, we misunderstood the spec and the feature doesn't do what it's supposed to do at all, or does it so poorly that it's unusable. This is the highest priority for a change request, but it is still a priority 2 - a change request can never take precedence over a blocker bug. These must be fixed by next release.
3. Important - Significant cost savings (or profit potential, depending on the kind of software), major performance enhancements, anything that will make the app more awesome. Or anything escalated to this level by management - this is the highest escalation level for a feature. Expected to go into next release but may be cut in the event of a time or cash crunch.
4. Normal - Basically something that a lot of people want (or one VIP wants), and the rationale for it is clear and reasonable, but there's nothing special about it that would warrant it taking precedence over any other run-of-the-mill request. Minor performance tweaks, add this field or this button or this report, make this sort as a number instead of alphabetically, that kind of thing. These get assigned to the next release, but are the first to get cut if any delays come up.
5. Low-Impact - Layout changes, wording changes, changes that might conflict with the baseline requirements, pie-in-the-sky features that could take months to implement, etc. These automatically get assigned to a future release unless we're not working on anything more important (which is... never). Often when the next release does go out, these will get deferred to an even further release as more important requests pile up.
6. Optional - We don't actually call it optional (I think officially it's "Time Permitting"), but that's pretty much what this is. Generally reserved for two classes of change: (a) dumb requests that we know will just annoy most people ("show a confirmation dialog every time the user tries to click this button"), and (b) internally-conceived features that we can't cost-justify above official requests. Not assigned to any release.
My team doesn't classify tasks by priority alone, we use three critical criteria: priority, severity, and visibility.
Priority refers to our development schedule. A high-priority bug or feature is one that is scheduled for completion in the current development cycle or has been promised to a customer by a certain, relatively soon date. An example of a low-priority task would be a bug in a feature that is still in early development and will not be on the official road map for some time.
Severity refers to the impact of the bug's presence or of the feature's absence (in the case of enhancement requests). Bugs that can screw up user data, damage hardware, or create a permanently un-recoverable situation have highest severity. If another important team within the company is stuck waiting on us to fix a bug or add a feature, then that task would have fairly high severity as well. Middle severity rankings are given to tasks like performance optimizations that are important but not required for the project to function. Low severity tasks are things like spelling errors in error messages or features that would help make internal debug/testing easier but aren't visible to the end-user.
Visibility refers to who can see the bug. A bug that would crash the software for every user upon start-up would be a high-visibility task. Bugs that are dependent on a specific, uncommon configuration or are only seen in our (or our partners') labs have middle visibility. Bugs inside internal debug and testing functions (and are not able to be encountered by the end-user) have the lowest visibility.
For each incoming bug, enhancement request, or planned feature/new development we assign a priority, severity, and visibility (abbreviated P/S/V) value between 1 and 5 (with 5 being the highest). Generally, we prioritize our efforts by sorting the 'to-do' list by the sum of the three values (loosely, it's a fuzzy logic system). A bug report with a P/S/V of 2/5/4 would be worked on before a new development task with values 5/1/3, but only after the enhancement request with values 5/2/5.
This is (of course) an inexact science, and there are always exceptions to the system. Sometimes handling a lower-ranking enhancement request is preferable if it will also work around a higher-ranking bug. For all tasks with a ranking of X, the bugs with rank X are usually tackled before the enhancements of rank X. We usually also consider all rankings to have a +/-1 margin of error.
A drawback to this system is that it doesn't take into account the length of time that a task has been on the to-do list (some old, stale tasks can hang around for a long time) or the estimated length of time that the task will take to complete. Fortunately, we have enough people on our team that we can afford to have someone spend a day clearing out some low-ranking tasks every now and then.
Officially our company had a strict "fix bugs first, then write new features" policy. However, the few people who actually seemed to uphold it were also the ones who were most important in terms of new development. It took a while, but we realised that fixing a bug that will make one client happy is less important than adding a new feature which will make a 100 clients happy.
In addition, our products are so big by now, that it would take years to truly fix all the bugs, this is not an acceptable timespan for a complete lack of new features/versions.
At this point, since we have a very decent bugtracker and crash-dump system, pretty much all the easy bugs have been fixed, and we've taken to the notion that many of the remaining ones are annoying, but no show-stoppers.
Bugs that can be fixed in less than 2 hours first, then the ones that required more time.