Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 42599 invoked from network); 2 Jun 2006 18:08:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 2 Jun 2006 18:08:29 -0000 Received: (qmail 31467 invoked by uid 500); 2 Jun 2006 18:08:26 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 31409 invoked by uid 500); 2 Jun 2006 18:08:25 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 31398 invoked by uid 99); 2 Jun 2006 18:08:25 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Jun 2006 11:08:25 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of jason.dillon@gmail.com designates 64.233.162.199 as permitted sender) Received: from [64.233.162.199] (HELO nz-out-0102.google.com) (64.233.162.199) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Jun 2006 11:08:25 -0700 Received: by nz-out-0102.google.com with SMTP id m7so560641nzf for ; Fri, 02 Jun 2006 11:08:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:mime-version:in-reply-to:references:content-type:message-id:subject:date:to:x-mailer:from:sender; b=S1lrH7DvgX+pnSlF3VRnr0idcd6RFwh7v0M/vPJqnH6cCl5FiQTJMgBiktEHrcD3WwJRHM5VcXn/A7nV0ymkQNbA1GHF7LzF7BZJEDyPI8KohPizVJGY+aAxOQqgtCERPsrpTX4J03ZqVwSAvq3OT2oSWue4xqbBXGPy7zpkmVs= Received: by 10.36.247.54 with SMTP id u54mr2695322nzh; Fri, 02 Jun 2006 11:08:04 -0700 (PDT) Received: from ?10.0.1.19? ( [67.180.143.96]) by mx.gmail.com with ESMTP id 36sm1572313nzk.2006.06.02.11.08.03; Fri, 02 Jun 2006 11:08:04 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) In-Reply-To: <44806CB7.9080206@hogstrom.org> References: <44806CB7.9080206@hogstrom.org> Content-Type: multipart/alternative; boundary=Apple-Mail-4--834210490 Message-Id: <15CCA258-B344-4594-A417-BD242A9AD331@planet57.com> Subject: Re: Thoughts on using JIRA more effectively Date: Fri, 2 Jun 2006 11:08:01 -0700 To: dev@geronimo.apache.org X-Mailer: Apple Mail (2.750) From: Jason Dillon Sender: Jason Dillon X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --Apple-Mail-4--834210490 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Can we mark some of the older M* builds are archived? That will help make the "Raised In Versions (non-archived))" portlet more useful. I'm curious... has everyone setup their JIRA home/dashboard to show more details specific to Geronimo... if not, I'd recommend creating a new "Geronimo" portal page and add project portlet for Geronimo, and probably a few project statistic portlets (like "Raised In Versions (non-archived))"). I pinged infrastructure about possibly upgrading JIRA, the newer version has some good features that will help us. I'm also going to ask them if we can get the Toolkit plugin installed and configured, as this has some really helpful additions (like one that will color older outstanding issues different, and another that will show all of the folks that participated in the issue). --jason On Jun 2, 2006, at 9:52 AM, 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. > > 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. > > 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. > > For new issues that are not being worked on they get put into > another category like 1.x, wishlist, etc. > > 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? > > Rather than pushing the morass of JIRA's in 1.1 into 1.2 and > repeating our previous behaviour I'm using 1.x, wishlist and > Verification Required as the dropping point for JIRA's out of 1.1. > For those things we can work on in 1.2 they'll get moved there. > > This will make releasing a whole lot easier from a goat herding > perspective. > > I am not an Administrator and don't play one on TV but this > elephant has been in our living room too long :) > > Matt --Apple-Mail-4--834210490 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Can we mark some of the older M* = builds are archived?=A0 That will help make the "Raised In Versions = (non-archived))" portlet more useful.

I'm curious... has = everyone setup their JIRA home/dashboard to show more details specific = to Geronimo... if not, I'd recommend creating a new "Geronimo" portal = page and add project portlet for Geronimo, and probably a few project = statistic portlets (like "Raised In Versions = (non-archived))").

I pinged infrastructure = about possibly upgrading JIRA, the newer version has some good features = that will help us.=A0 I'm also going to ask them if we can get the = Toolkit plugin installed and configured, as this has some really = helpful=A0additions (like one that will color older outstanding issues = different, and another that will show all of the folks that participated = in the issue).

--jason


On Jun 2, = 2006, at 9:52 AM, Matt Hogstrom wrote:

Having done two releases I have some thoughts on how = we are using JIRA.=A0 I = imagine that there are a number of thoughts on how we can manage = JIRA.

Currently we create a release and then pretty much = dump most everything into it.=A0 = 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.=A0 = I don't think this solution works because one never knows what's = really left in a release to complete before its golden.=A0 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.

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.

For new issues that are not = being worked on they get put into another category like 1.x, wishlist, = etc.

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 =A0 .=A0 Thoughts?

Rather = than pushing the morass of JIRA's in 1.1 into 1.2 and repeating our = previous behaviour I'm using 1.x, wishlist and Verification Required as = the dropping point for JIRA's out of 1.1.=A0 For those things we can work = on in 1.2 they'll get moved there.

This will make releasing a whole = lot easier from a goat herding perspective.

I am not an = Administrator and don't play one on TV but this elephant has been in our = living room too long :)

Matt
=

= --Apple-Mail-4--834210490--