Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: pass (herse.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=SWVYAYXlwj3c4FB07uOdF55ji9eaTj66AVCrElusLbrGc0Ty0YFWDUMUnRTFCnDbZw1kCg/ReQSM6FYMiM6ShqWv+uk2/KvVxpCSwl0LAuQXRrOJHrpghDjLVExMGQXNIAslV1TvmAeiIq6yLOWJzz7kAVeb6orJUyA46BN53ug=
  ;
Message-ID: <20061026034925.31921.qmail@web50307.mail.yahoo.com>
Date: Wed, 25 Oct 2006 20:49:25 -0700 (PDT)
From: Otis Gospodnetic <otis_gospodnetic@yahoo.com>
Subject: Re: jira workflow
To: java-dev@lucene.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ascii
Content-Transfer-Encoding: quoted-printable

I think we want to keep things as simple, yet organized.=0AAssigning issues=
 to oneself is really useful for issues that require more time, so it's cle=
ar who's working on them.=0AI probably made a mistake assigning myself that=
 one issue just to commit it.  I wanted to signal I'd take care of it, but =
I should have really just committed the patch and marked the issue resolved=
.  That is how we have been working so far, and it has worked for us, so I =
don't think we need to change that.=0AHadoop developers have a pretty elabo=
rate JIRA workflow with a number of specific states, but I think they need =
that because Hadoop is still in a rapid development mode.  Lucene is in a d=
ifferent life stage.  I'm really talking about issue assignment part of the=
 workflow here.  "Patch available" is handy.=0A=0AOtis=0A=0A----- Original =
Message ----=0AFrom: Steven Parkes <steven_parkes@esseff.org>=0ATo: java-de=
v@lucene.apache.org=0ASent: Wednesday, October 25, 2006 1:14:19 PM=0ASubjec=
t: RE: jira workflow=0A=0AFollow up on the workflow stuff:=0A=0AWith a larg=
er group of people able to work at the Jira level, do we want=0Ato have an =
approach to assignee? Otis was getting ready to commit a=0Apatch I had shep=
herded through and assigned the issue to himself in the=0Aprocess. This is =
what's always been done in the past, but in the past=0Acommitters  and deve=
lopers/contributors were pretty much synonymous.=0A=0ASince that's not the =
case now, I'd suggest it's reasonable for a=0Acommitter to commit w/o chang=
ing the assignee, only changing the state=0Ato resolved. Facilitates commun=
ication on issues that might arise later=0Aand helps gauge individual invol=
vement.=0A=0AI suppose there's the possibility that two committers might be=
 looking=0Aat committing something at the same time, though I think comment=
s cover=0Athat?=0A=0ASeem reasonable?=0A=0A--------------------------------=
-------------------------------------=0ATo unsubscribe, e-mail: java-dev-un=
subscribe@lucene.apache.org=0AFor additional commands, e-mail: java-dev-hel=
p@lucene.apache.org=0A=0A=0A=0A

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org