RSS Feed

FogBugz Technical Support

Commonly there is a severity field set by the bug reporter, and a priority set by the project manager.

Was this a design decision? I'm a bit dissapointed that this isn't configurable.

We really don't like adding fields:
http://www.joelonsoftware.com/news/20020912.html

But the severity field is especially tricky.  I'm not sure how it is different than priority.  I understand how you could have a high severity bug, that is low priority (like if you hold down ctrl+k+q+z and give the computer screen bad looks, the program erases all your data.  Not worth fixing, but its a scary bug).  Or a high priority bug that is low severity (like you mispelled your company logo in the product).  But in practical use, the first one won't get fixed (low pri) and the second one will (high pri), and severity doesn't even matter.

I've just never understood why you need both.

The previous bug-tracking system we used at work had a "severity" field other than priority.

We found that users always set the worst severity, regardless of what the bug was so I'm not sure such a field has all that use. If your users are disiplined enough then perhaps. But having a problem like "If I open up the report viewer, there's a gray line down the right of the report. It's not printed, but it's visible on screen" tagged as "critical" wasn't very useful to us.

I for one find it better with just one field, priority, as that simplifies the whole process.

The function of the severity field is basically as described in the previous posts. The significance is the severity is set by the person reporting the bug, the priority is set by the project manager. They have completely different meanings.

If all cases are being reported as the highest severity, that reflects poorly on the quality of the QA being performed, but doesn't mean the severity field itself is invalid.

The data can also be useful for reporting. A high number of severe bugs in a particular area of the application would indicate a problem, where a proportionally high number of minor bugs would not necessarily be cause for concern.

I understand that some users would not find it useful, considering most of the people posting don't even understand how to use it. However, to exclude the ability to retain that data simply because not everyone will is annoying.

It should simply be included as an optional field. Adding such basic flexibility to the product would not require much effort. The attitude that "if we don't use it we won't provide it" just marginalizes the value of the product.

I don't think I'd recommend FogBugz over competing programs because of the lack of customization available.

-- It should simply be included as an optional field. Adding such basic flexibility to the product would not require much effort. The attitude that "if we don't use it we won't provide it" just marginalizes the value of the product. --

It's true that adding such a field would be trivial, but our motivation from the start of FogBugz was to create a product that works for people.  With this in mind, there are things we *intentionally* leave out, to keep with the philosophy we have regarding the best way to manage software projects.

The entire goal of FogBugz is to create the best project management tool, that people actually use.  In keeping with that, we purposefully keep field creep from setting in because we know people are less likely to enter bugs with the more fields there are.  It starts out marginal, but builds up quickly.  Severity is a field that we've decided is better served as priority.

Well for me personally, a product that works for me is one that facilitates the way I work, rather than dictating someone elses idea of what is best. In my next project the tool I actually use will likely be Dragnet.