trac-admin initenv puts severity values into priority field

[Bartek Jarocki <spam@…>]

Problem

current trac-admin initenv (rev. 2040) puts severity values into priority table while severity table remains empty

Test

svn co -r 2040 https://svn.edgewall.com/repos/trac/trunk trac 
cd trac/
export PYTHONPATH=$PWD
./scripts/trac-admin test_env initenv 
# ... all paths provided

severity:

./scripts/trac-admin test_env severity list

Possible Values
---------------

priority:

./scripts/trac-admin test_env priority list

Possible Values
---------------
blocker
critical
major
minor
trivial

[mgood]

Yes, this is expected. With the introduction of the "Type" field to distinguish bug vs. enhancement the severity and priority fields had almost no difference in functionality, so only one was necessary. The severity table is left in place to support projects that have upgraded from an earlier version, but for new projects where there are no severity values defined the field will not be displayed in the UI.

[Bartek Jarocki <spam@…>]

I understand, fair solution. But wouldnt you find "lowest, low, normal, high, highest" values more appropriate for priority?

[anonymous]

I respectfully disagree. Severity is how important the bug is (does it cause a crash?) but priority is when to do it. Very low severity bugs can be high on priority list if they annoy users for instance. is it possible to keep both priority and severity?

[Bartek Jarocki <spam@…>]

I think you're right it is very useful to have both of them. But as I understand it is expected to use ticket's 'Type' to model severities (put there defect-blocker, defect-major, etc.). This semantic change is making severity field redundant and tickets more general for project management purposes (eg. "task").

It is a bit "extravagant" but personally I like it, except I insist that trac-admin initialised priority values are just wrong so I rename and reopen the ticket.

[anonymous]

That's true, priority values are wrong.

Offtopic: to me it would make sense to have different types of defects if they behave differently, e.g. workflow for defect-blocker is different from that for defect-major, or one of them would require different approval type for closing or higher access level. In truth, these two workflows are the same. Good example for this line of thought is defect-security that of course has different workflow, so I'd agree to add it as a new type. Also, if it's problematic or impossible to change type, nobody would be able to promote "major" defect to a "blocker," and that's going to be a really big problem. One more reason to have severity as a field is that acceptance criteria frequently include the clause "no defects of level blocker or major are open."

[cboos]

It might be interesting to read the TicketTypes page, where the rational behind the ticket type field is explained.

Some specific answers to the points raised in the comments above:

• it is perfectly possible to keep both priority and severity fields, even for new installations: simply use the trac-admin and then use the priority and severity commands to change/add values for them. It's just that by default, a simpler model is implemented, and this is having only the priority field, populated with the values formerly attributed to the severity field in trac < 0.9 (I'm also not so happy with that choice, but this has been debated at length...)
• it is NOT expected to use ticket's 'Type' to model severities! Previously, the severity field was abused to model the 'Type' (e.g. the enhancement value) and this motivated the introduction of the type field: we certainly don't want the reverse situation to happen, now. As said above, if both concepts are needed, then both fields are available and should be used.
• the Offtopic note about different workflows for different ticket types is an interesting suggestion. On a related note, it has already been requested that different ticket types should have different fields.

[cmlenz]

#2220 has been marked as duplicate of this ticket.

[mgood]

cmlenz made some good comments on #2220 about the reasoning behind the change in the priority values, so I'll quote them over here. I think that the default priority values are more descriptive than before and as cmlenz observes JIRA uses them as well, so there is prescedence outside of Trac for this. Users who prefer something else are free to change the values as they please, so I see no reason to leave this ticket open.

Cmlenz's comment on #2220:

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.

[dju`]

So, what is the meaning of priority? How can I express that a very important task, unscheduled in any milestone, has a low priority, ie. it has to be done after many other tasks/bug resolutions/enhancements. Setting a value of "minor" for the priority hides the fact that the task is important, and setting a value of "critical" hides the fact that this task isn't a priority right now. My preference would go to set a "critical" priority, because this is what importance the task has, and setting no milestone would express the fact that this task shouldn't be done asap. But I'm afraid the "priority" term isn't adapted though, and I (and other developers as well as users) would forget to think "priority" as "importance of benefit" instead of "when to resolve it".

[cboos]

Well, then simply ignore the default setting which is clearly not adapted to your use, and restore the "old" behavior, e.g.:

#!/usr/bin/env bash

: ${TRAC_HOME:-/my/trac/install/if/not/already/set}
: ${TRAC_ENV:-/my/trac/env/if/not/already/set}


NEW_PRIORITIES=( highest high normal low lowest )
NEW_SEVERITIES=( blocker critical major normal minor trivial )


TRAC_ADMIN=$TRAC_HOME/scripts/trac-admin


ta() {
  $TRAC_ADMIN $TRAC_ENV "$@"
}

ta-list() {
    ta $1 list | sed -ne 's/^--*$//;T;:o;n;p;bo' 
}

echo "Old settings for priority and severity"
ta priority list
ta severity list

# removing old values

for val in `ta-list priority`; do
  ta priority remove $val
done

for val in `ta-list severity`; do
  ta severity remove $val
done

# setting new values

for val in ${NEW_PRIORITIES[@]}; do
  ta priority add $val
done

for val in ${NEW_SEVERITIES[@]}; do
  ta severity add $val
done

echo "New settings for priority and severity"
ta priority list
ta severity list

[dju`]

Yes I know I can change everything, but I just want to stay as close as possible to defaults. I think I'll keep the priority field, and use custom fields for my own needs.