Matt Hogstrom wrote:
John Sisson wrote:
Henri Yandell wrote:
On 6/2/06, Matt Hogstrom <[EMAIL PROTECTED]> 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
- Re: Thoughts on using JIRA more effectively John Sisson
-
