geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Hogstrom <>
Subject Re: Thoughts on using JIRA more effectively
Date Sat, 03 Jun 2006 03:13:44 GMT

John Sisson wrote:
> 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.

I agree with the idea that we are peers but I think people have natural areas of expertise
that fall 
out.  (Well, apart from Jencks who seems to be able to do anything :-)

In general though I might change something related to a bug or a performance problem but know
if its Tx related I'll call on Jencks, or Console related give Aaron a heads up.  I don't
having people that are knowledgable in a given area as a main contact is an issue.  However,
also need to look at the needs of the project and help mentor folks as well.

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

Excellent idea John.  I'd like to coalesce the thinking in this thread and put something like
together.  Are you volunteering :)

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

View raw message