geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Re: Thoughts on using JIRA more effectively
Date Fri, 02 Jun 2006 18:52:53 GMT
Here's what I'd like:

 - a prioritized list of stuff I plan to work on for a release (where
the priorities are priorities on my list, not necessarily
corresponding to severity of problem, etc.)
 - a list of bugs that *someone* ought to look at for a release
 - features (and more rarely, bugs) that should be looked at, but not
in the current release
 - features that people have asked for but are not possible in the near term
 - a screen showing issues with attached patches, perhaps by priority,
perhaps by component

I don't like a large bucket of issues with no version assigned.  It's
my feeling that this bucket quickly gets out of control and no one
looks at those issues (in part, due to it's size, and in part, because
they're not on anyone's radar).  If I *do* look at such an issue, I
want to put it somewhere, to indicate that it's been reviewed, and
when I think it ought to be looked at.

I'd definitely be in favor of allocating some time in the immediate
post-1.1 time frame for reviewing and fixing the numerous bugs
relating to NPEs or terrible error messages if deployment plans are
slightly incorrect.  It would be great to clean all those out so we
could then focus on more important issues for 1.2, etc.


On 6/2/06, Matt Hogstrom <> wrote:
> Having done two releases I have some thoughts on how we are using JIRA.  I imagine that
there are a
> number of thoughts on how we can manage JIRA.
> Currently we create a release and then pretty much dump most everything into it.  What
ends up
> happening is that we end up with more JIRAs than we have time to complete and end up
with over a
> hundred JIRAs than move from version to version.  I don't think this solution works because
> never knows what's really left in a release to complete before its golden.  Our intentions
are noble
> (let's fix all those bad bugs) but of course our time is a limited resource and we can't
always get
> everything done.
> I propose (this is not a vote; simply a discussion thread) that new JIRA's are assigned
to a release
> if the person assigning it is going to fix it and they assign it to themselves.
> For new issues that are not being worked on they get put into another category like 1.x,
> etc.
> I'm not sure how to handle assignment of JIRAs as they generally fall into someone's
area of
> expertise but I think the fact their assigned to someone might scare someone away from
looking at it
>    .  Thoughts?
> Rather than pushing the morass of JIRA's in 1.1 into 1.2 and repeating our previous behaviour
> using 1.x, wishlist and Verification Required as the dropping point for JIRA's out of
1.1.  For
> those things we can work on in 1.2 they'll get moved there.
> This will make releasing a whole lot easier from a goat herding perspective.
> I am not an Administrator and don't play one on TV but this elephant has been in our
living room too
> long :)
> Matt

View raw message