geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell" <flame...@gmail.com>
Subject Re: Thoughts on using JIRA more effectively
Date Fri, 02 Jun 2006 17:17:17 GMT
On 6/2/06, Matt Hogstrom <matt@hogstrom.org> 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.

I tend to do release management tasks too, so thought I'd offer thoughts.

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

At first I thought this was bad, but the existence of a 1.x version
means that you can still keep the vision of the major release going
without making it hard to do minor releases. Seems like a good idea to
me.

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

Probably a bit too far. The process here is going to depend on when
you branch the release, so:

*) pre-branch - general conversation about the important things in
this release (and are thus assigned to 1.2 etc), people fixing things
randomly and throwing in (and as they resolve they move to 1.2 - there
should be no resolveds in 1.x).
*) post-branch - nothing should move to 1.2 without lots of discussion.

> For new issues that are not being worked on they get put into another category like 1.x,
wishlist,
> etc.

New issues are unversioned. Component leads look at the issue and then
assign them to 1.x, wishlist, 2.x, verification required, wontfix
(resolving) et al.

Maybe have a weekly report of unassigned issues so the release manager
can nudge people.

I always have an urge to have IRC triage sessions with decisions
reported back to the mail list, interesting to hear what Ken thinks on
that.

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

I would define leads for each component and delegate to them as
release manager to give me a status of where things are - however I
would make the default assignee be unassigned to encourage community.

Hen

Mime
View raw message