Previously I talked about wanting to separate priority and severity in Roundup and proposed some severity levels:
At the time I left open how to handle features and what priority levels could be.
I just did a Google search on 'priority severity'. My previous blog entry was actually the first hit. The second hit was a page on the original c2 wiki espousing the principle DifferentiatePriorityAndSeverity.
Some commentators suggested a distinction was a nice idea in theory but too hard for submitters in practice. What I am suggesting, though, is that the submitter need only worry about severity, the developer fixing the bug about priority and only the people responsible for triage really need to worry about the relationship between the two.
One commentator mentioned Microsoft's severity levels as being:
This seems reasonable, although the second and third might get blurry unless it's clear what the granularity of a "feature" is (which is probably spelt out in specs at Microsoft). It also doesn't take into account whether a workaround exists which I think is important.
I do like the calling out of a crash or loss of data. And I did have a slight problem with my own earlier list in distinguishing "major" and "minor" which the Microsoft list doesn't worry about.
With regard to features, I think it is helpful to distinguish new features from enhancements to existing features. This may suffer from some of the same granularity problem mentioned earlier for the Microsoft severity levels but I think it makes sense in the context of a particular project's plan.
As I mentioned in my previous entry, I think there's also a need to handle code cleanup, refactoring and other internal enhancements. I previously suggested a possible separate class, but I think it can be done with severity. I think it also helps to have a catch-all "general tasks" for when it isn't clear there is (yet) a suitable level to assign the issue to.
So one possible severity level list would be:
Note that in both the B-series and E-series, the lower number means greater significance.
Next up, some thoughts on priority.
by : Created on Jan. 3, 2005 : Last modified Feb. 8, 2005 : (permalink)
I've talked about the difference between priority and severity and proposed possible severity levels. Here's my current thinking on priority levels in issue tracking systems for software development (and specifically Leonardo's Roundup tracker).
Most systems I've seen simply use numbers for priorities: P1, P2, P3, P4 and P5, for example. To really know which one to use, groups end up assigning particular meaning to them.
Outside of software development, I've found it useful to think of priority in terms of modals like:
and, where appropriate adding things like:
I think it's useful in software development to think of those modals in the context of releases. e.g. this bug must get fixed for 0.5 or that enhancement should get in 0.6.
This is already better than P1-P5 but there are some complications that need to be addressed.
Firstly, if one assumes that maintence patches are still taking place on previous releases, it is possible for issues to have priorities relative to multiple releases. For example, a bug might be a "must for 0.5" and a "should for 0.4.1". How would one express that in an issue tracking system?
Secondly, one probably needs finer grained priorities on occasions when, of the 20 things that must or should get into the next release, there are 5 that must get done in the next week and another 5 that should.
The second is less of an issue for Leonardo in my opinion, but it would still be nice to address.
One way of addressing the former, especially if one assumes that one is only actively maintaining one version prior (reasonable at this stage of Leonardo at least) is to have separate priority fields: one for the upcoming patch and one for the upcoming new version.
So both "patch priority" and "trunk priority" could have values like:
What priorities have others found useful?
by : Created on Jan. 3, 2005 : Last modified Feb. 8, 2005 : (permalink)
A friend called me last night asking whether "number of casualties" is singular or plural. Apparently the words had been uttered by a reporter and there had been some debate at the friend's house as to whether the reporter had got the agreement between the verb and subject correct.
My intuition was that the following are both grammatical:
and that a with was and the with were would both be ungrammatical.
Thinking about it some more, I came up with another example pair.
That made things a little clearer to me (although looking back at the original pair, it's now obvious there too). With the indefinite article a, the heads of the phrases are casualties and people (both plural) whereas with the definite article the, the heads of the phrases are both number (singular).
In "a number of casualties were reported", it's the casualties that were reported; in "the number of casualties was reported", it's the number that was reported.
Even more clearly, in "a number of people were high", it's the people that were high; in "the number of people was high", it's the number that was high.
That would all suggest structures along the lines of:
The structure explains the subject-verb agreement and the semantics.
The interesting question in my mind remains: what it is about the article that determines which structure is licensed in each case?
by : Created on Jan. 3, 2005 : Last modified Nov. 2, 2005 : (permalink)