tags:

views:

21

answers:

1

I use Trac regularly in a team at work, as well as for my own project for the university. In both cases I have never felt the need to use the severity property for a ticket. I feel that by using the type and priority properties gives all the information I need, and I cannot think of anything to do with the severity property that would not be redundant. Does anyone have any good usecases for the severity-property?

+1  A: 

You can treat priority and severity as orthogonal values.

The severity can indicate how costly the bug is: low severity could be "the color of this icon is wrong" and a high severity could be "computer hunts down and kills user".

The priority is how urgent it is to fix the problem. An icon that uses the company's biggest competitor's corporate color may be high priority, whereas a deadly error that can happen once in a million years may be a low priority.

You can then work on things based on the priority times the severity; something that is medium severity and medium priority may be more important than something that is low severity and high priority.

OR

You can give the ticket owner control of the severity, and the developer control of priority. That gives you a way to see where views differ without having edit wars over the single priority field. But done naively, users will simply set the severity to the greatest value they can, and you lose all usefulness in that field. (And no, I don't pretend to have a useful, tested-in-the-real-world solution to that. There are lots of possibilities to play with though.)

But honestly, a single priority field of high/medium/low has worked well enough for me in all of my projects. A separate severity field just seems like additional complexity for negligible benefit.

Discloser: I'm one of the Trac devs

retracile