cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
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.
>>[1] http://issues.apache.org/bugzilla/page.cgi?id=fields.html#bug_severity
>>
>>In my opinion Jira has these two concepts mixed up
>>together.

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
>>e.g. http://issues.apache.org/jira/browse/FOR
>>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
>>[2] http://marc.theaimsgroup.com/?t=113213094300001
>>http://marc.theaimsgroup.com/?l=forrest-dev&m=113334665915625

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 ...




[1] http://www.onlamp.com/pub/a/onlamp/2005/08/11/fixingbugs.html
[2] http://www.onlamp.com/pub/a/onlamp/2005/08/11/fixingbugs2.html



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

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

                                        web(log): http://www.poetz.cc
--------------------------------------------------------------------

Mime
View raw message