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 Mon, 05 Jun 2006 01:45:09 GMT
Point well taken as that certainly could bubble up as a problem if one person was elevated
other in the group.

John Sisson wrote:
> Matt Hogstrom wrote:
>> 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 that if its Tx related I'll call on 
>> Jencks, or Console related give Aaron a heads up.  I don't think 
>> having people that are knowledgable in a given area as a main contact 
>> is an issue.  However, they also need to look at the needs of the 
>> project and help mentor folks as well.
> I agree that people have natural areas of expertise.  I am just wary of 
> seeing people marketed as the "Leader of component/team X" by their 
> employers or in articles/books (and they have the JIRA screen to back it 
> up without an explanation of what it really means).  What if two people 
> consider themselves experts in a component, AFAIK, JIRA can only have 
> one lead for a component? Will one get upset at the other being chosen 
> as the Lead?  How is a lead selected and what is the length of their term.
> In a perfect world I wouldn't see any problems with this, but I can see 
> some potential issues here.  What do others think?
> John
>>>> 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 that together.  Are you volunteering :)
> I would be happy to put together a page similar to Derby's for review, 
> I'll created GERONIMO-2080 and assigned to myself.
> John
>>>> 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