cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <>
Subject Re: Jira: better use of the Priority field
Date Thu, 22 Dec 2005 08:46:22 GMT
David Crossley wrote:
> I wonder if people just missed this topic in the
> volume of recent discussions. And two days before
> the silly season is probably not a good time to
> try to revive it :-)

Recently I came across those two articles [1][2] and I think some points of the 
author are interesting for OS projects too. Especially I refer to the 
distinction between priority and serverity (more or less the same as you do in 
your mail).

> David Crossley wrote:
>>At Apache Forrest we have discovered some problems with
>>the ASF Jira. Cocoon is going to hit these same issues.
>>So i wonder if we can address it together. There are
>>evidently some people on cocoon-dev who have used
>>Jira extensively. Perhaps we need customised screens.
>>Jira has a field called "Priority" which has the values
>>Blocker, Critical, Major, Minor, Trivial.
>>ASF Bugzilla has a different concept. It has a field
>>called "Severity" with those same values. It has another
>>called "Priority" which has values like p1, p2, p3, etc.
>>The Buzilla "Severity" means the impact of the issue
>>(e.g. Blocker means that it prevents development).
>>The "Priority" means the importance and order in which
>>it should be fixed.
>>In my opinion Jira has these two concepts mixed up

yes, I agree here

>>Some other project (Xalan?) has already added a custom
>>field called "fix-priority". Should we add that field
>>to our issue screens and reports?
>>This becomes confusing at the front page of a project
>>where "By Priority" is listed in the bottom-right.
>>They are not actually our priority for fixing the
>>issues, but a list of the perceived severity.
>>There is an additional problem. Forrest has separate
>>"Plugins" and Cocoon has separate "Blocks". A Blocker
>>in a Plugin is not necessarily a Blocker for the project
>>as a whole.

right, this is one of our goals with splitting up Cocoon into blocks

>>This makes it difficult for the developers to plan what
>>to work on next and which issues need to be fixed for
>>the upcoming release. It also gives an unrealistic view
>>of the state of the project.
>>So do people here agree with those problems?

I agree

>>Do you see a workaround? Perhaps rename "Priority" to
>>"Severity" and also list "fix-priority" on the front page
>>and on the issue screens.

I think JIRA should be flexible enough.

>>Ross recently asked at ASF Infrastructure about the
>>wider issue of separate "sub-projects". See the answer
>>and other discussion about this topic at forrest-dev

Each block is a component in JIRA and I can get a summary of all open issues for 
a component. Hmm, I think that I don't understand completly the problem that you 
want to solve ...


Reinhard Pötz           Independent Consultant, Trainer & (IT)-Coach 

{Software Engineering, Open Source, Web Applications, Apache Cocoon}


View raw message