I'm a big fan of roundup as a bug tracking system. It does, however, come with an odd list of default priorities:
One thing I don't like about it is that it conflates priority and severity. I think it's useful in a bug tracking system to distinguish priority and severity. While the two are often related, it is possible to have a high-priority low-severity bug (e.g. embarrassing typo in UI the day before an important customer meeting) and a low-priority high-severity bug (e.g. software crashes on an unsupported OS)
Severity, in my view is, about the impact on what the user is trying to do. Severity is fairly easy for the submitter to judge. Priority, on the other hand, is more of a triaging issue that needs to take into account a number of factors the submitter might not be privy to. So priority is best assigned in some separate review session. That is not to say the submitter can't be involved in that review — just that others need to be involved too so priority can't generally be judged at the time of submission.
Here is a list I came up with a few years ago for the severity of bugs:
Any alternative lists people have used and found useful?
Note that features aren't included here. I'm not sure that features should be treated as a level of priority or severity. I like the approach of them being a completely different issue type. I also think there's value in having a "task" type which covers things that aren't features or bugs but nevertheless benefit from being tracked. The only problem I see with different types is that, as a developer you really want to see all your issues at once, whether they be features, bugs or tasks. It isn't clear to me how one would do that in roundup.
UPDATE (2005-01-03) : Now see More on Priority and Severity
The original post was in the category: software_craftsmanship but I'm still in the process of migrating categories over.