priority/severity misunderstanding.

[dju`]

This covers several questions:

1. Why are default priority values going from "trivial" to "blocker", and default severity list is empty? IMO, "trivial" to "blocker" values express the idea of severity (importance of the defect/enhancement/task), and default priority would better go from "lowest" to "highest", just as in the 0.8 series. What are the reasons of this switch?
2. Why has the "normal" "priority" (ex severity) doesn't exist by default?
3. Why is the severity (ex priority) list empty by default?
4. As "priorities" (ex severities) apply to any type of ticket (defect/enhancement/task), I'd like to see "blocker" not appear by default, as it has, I think, no meaning for enhancements and tasks, and as "critical" and "blocker" look very similar for bugs and could be merged.

[Christian Boos]

I also don't like too much the new scheme. When I introduced the ticket types, it was mainly to have a high-level distinction between bugs and features requests (visible in the timeline) and to make it possible to associate a severity to the feature requests (e.g. trivial, minor, major, critical)…

The point of the other Trac developers was that ticket types + severity + priority would be overkill most of the time.

Then, several people expressed their wish to keep that flexibility, so the compromise was to keep the three fields but to have one of them inactive by default for new installations. That's why Severity is not enabled by default and Priority has the old Severity values (that last point is the most controversial, IMHO).

It's often said that, for instance, a critical bug should always deserve highest prio, so having both fields is redundant.

At least, if we don't re-enable the severity field, the default priority values should be more intuitive and look more like priorities:

highest, high, normal, low, lowest

[Christopher Lenz]

cboos proposed and implemented the extension of the Trac ticket model by a ”ticket type“ field. And after much debate and tweaking, the proposal was merged.

Now that enhancement requests were no longer second clas citizens in Tracs ticket system, the severity field seemed out of place. “Severity“, defined as relating to “something bad or undesirable“ by the Oxford American Dictionary, does not make much sense for enhancement requests or tasks.

However, the severity values such as “blocker" or “trivial” do make sense for enhancements: you can have an enhancement ticket that blocks a release, i.e. it must be implemented. You can have “trivial” enhancements or “critical” enhancements. I think these values are quite a bit more intuitive than the generic “highest”, “higher”, etc values, which only make sense when you look at them relative to other tickets (i.e. you could just as well use some yucky star graphics ;-) )

So, following the lead of ​JIRA, we moved the severity values over into the priority field for new Trac environments, and disabled the severity field by default. (Note that this is not true for upgraded environments, which is another story altogether). As cboos states, another reason was to keep the number of default ticket fields down to something managable.

Looking at other issue trackers, I wasn't able to find any mainstream systems that by default provide two fields to convey the importance of a ticket, and also provide a field to differentiate between types of tickets. And I think that's not a coincidence.

Also, I'm pretty sure this is a dupe, but I have to yet find the original ticket…

[Christopher Lenz]

This is a duplicate of #1861.

[anonymous]

Trouble ticket systems used in a typical service desk environment usually set priority as a product of severity (degree of impact to the end user i.e. completely broke, broke but with workaround, working but annoyance exist etC), and business impact (how many users affected - eg All, more than xxx, less than xxx, Executive users). Each of these is given a value, and multiplying the two sets the priority.

This works in mush the same way that a risk register sets priority by combining impact x probability of risk turning into an issue.

ITIL provides some good guidance and definitions.