Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: domain of jrsisson@gmail.com designates
 64.233.162.194 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding;
        b=f5lGPvc1aSSw67UGfpDL2XlEkv0HgKs6//Py0wdAoOcs5oPamEU1pAP/rbExK3fkjwBDj3cHOhiceJc7x2yd6zfuO2WwHrEtl1PIolMLwDs8KJZaD/qfTPxdp5GR1Hpjoit/hnO6Q1n12mHMCqhnmvkX+Il8T9FLBHad5VyeaJs=
Message-ID: <4481117C.3090807@gmail.com>
Date: Sat, 03 Jun 2006 14:35:08 +1000
From: John Sisson <jrsisson@gmail.com>
User-Agent: Thunderbird 1.5.0.2 (Windows/20060308)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: Thoughts on using JIRA more effectively
References: <44806CB7.9080206@hogstrom.org>
 <31cc37360606021017kc415eb9v87ffc31445bb7c8a@mail.gmail.com>
 <4480E356.4030402@gmail.com> <4480FE68.3050801@hogstrom.org>
In-Reply-To: <4480FE68.3050801@hogstrom.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Matt Hogstrom wrote:
>
>
> John Sisson wrote:
>> Henri Yandell wrote:
>>> 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.
>> 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 http://db.apache.org/derby/DerbyBugGuidelines.html ) 
>> 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
>>>
>>
>>
>>
>>
>