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