geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Sisson <>
Subject Re: Thoughts on using JIRA more effectively
Date Sat, 03 Jun 2006 01:18:14 GMT
Henri Yandell wrote:
> 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.
> 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.
I am concerned that having Component leads is against the ASF way.  The 
last thing we want is for the community to feel there is a hierarchy and 
opening up the opportunity for people to claim they are the leader of 
component/team X.  Everyone should be a peer. 

> 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.
The IRC triage sessions are a good idea - with the importance on results 
being posted on the dev list.  Hopefully Jason will be able to get the 
IRC logs posted to the dev list, so no-one misses out on the detail.
>> 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?
If a JIRA is not marked as in-progress then people should be encouraged 
to ask the assignee whether they can take it off their hands.

I am also wondering whether we should have Geronimo Bug Guidelines page 
(e.g. like ) on the 
website off the JIRA link that discusses JIRA usage and may help prevent 
JIRA being used as a place to ask questions, with the link to JIRA on 
that page.
> 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.
I think we need more discussion on the pros and cons of having component 
> Hen

View raw message