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