Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of mikhail.a.markov@gmail.com
 designates 64.233.182.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=LD6Yv8W0Bkw00y7mLsBQVrEVhN67G7jz2+0F6IXHTyi+Q+zUK18Ywz2DOspd7OqDBzewQboWr7p5RdNAvLqyQ/5SjCGn5Oe9LA28gWahWrxK2Siicgkm0uBpdaTnez39UhbztpXBt74KsNEfE5hM+SqhUYgmC0bZaA0K9DwqNaU=
Message-ID: <51abf0750612140451g3a1d71bq6f3b675169cc8080@mail.gmail.com>
Date: Thu, 14 Dec 2006 15:51:33 +0300
From: "Mikhail Markov" <mikhail.a.markov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [general] Wise JIRA processing
In-Reply-To: <45811479.7060204@pobox.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_157360_33417353.1166100693287"
References: <51abf0750612132224x6f087cbbwab1f99f9d664aaf2@mail.gmail.com>
	 <458106C2.9030606@pobox.com>
	 <51abf0750612140058w1b31b8a4i70aadfa1dbe026d5@mail.gmail.com>
	 <45811479.7060204@pobox.com>

------=_Part_157360_33417353.1166100693287
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Ok, i'll try to write the picture as i see it (perhaps too innovative :-)):

General:
There are currently (Apache standard) 2 roles: contributors & committers
(contributors could open JIRA, assign patches, committers could modify
JIRA(reopen, close etc.) and commit the code). People are gained committer
status when they demonstrated significant dedication to the project etc.
Roughly speaking, the distribution is 3% - committers, 97% - contributors

The suggestion is to have 3 roles: contributors, "JIRA contributors" (or
whatever...) & committers. JIRA contributors could modify JIRA. People are
gained JIRA contibutor status also when they demonstrated significant
dedication to the project, but less, or less significant :-).
Some JIRA could be resolved without any commits to svn (not reproducible,
for example), so JIRA contributors could resolve such issues.
I think that having 30%-40% of people having full JIRA access will be
enough.

Why:
If we think of development in a private company working on not too large
project, then usually everybody have full access to bugtracking system so
people could easily reassign/close etc bugs and at the same time people
discuss technical details in the mailing list. Of course Harmony is open
source, but we strive to become "world class, certified implementation of
the Java Platform Standard Edition" we could utilize such experience for
quicker JIRA processing. As there are usually a lot of JIRA, but little
number of committers, whose primary role, imo, applying patches (if they
don't do it, then who would? :-)), they might be busy with this activity and
have no time for everything else, this adding new role could help quicker
deal with issues which do not require committing. At the same time i do not
think people will less talk and discuss in the mailing list.

(Also particular answers inlined below.)

Regards,
Mikhail


On 12/14/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
>
>
>
> Mikhail Markov wrote:
> > On 12/14/06, Geir Magnusson Jr. <geir@pobox.com> wrote:
> >>
> >>
> >>
> >> Mikhail Markov wrote:
> >> > HI!
> >> >
> >> >
> >> > In my opinion, it's hard to track open JIRAs now.
> >> >
> >> >
> >> > For example, if the JIRA is not assigned then there is no simple way
> to
> >> > understand if there's activity in there except opening it in
> >> web-browser
> >> > and
> >> > reading comments.
> >> > Only committers could modify the status of JIRAs and put them "In
> >> progress"
> >> > mode. As we have not so many committers they could not monitor large
> >> number
> >> > of open JIRA.
> >>
> >> I'm not sure how your solution helps this.  Can you explain?
> >
> >
> > Just plain statistics (for classlib):
> > Open JIRA #: 425
> > Assigned JIRA #: 52
> > Reopened JIRA #: 6
> > In progress JIRA #: 5
> > It's not easy to answer the question: "are there any activity in other
> open
> > JIRA?"...
> > The only indicator is "In progress" tag. Only committers could set this
> > tag,
> > but as the number of JIRA is rather large they could not monitor
> > everything.
> > The proposal is to increase the number of "JIRA masters".
>
> Does this really solve anything though?  To monitor the progress, you
> have to open each JIRA anyway.


To monitor progress - yes, to see is there any progress at all - no.


The only thing that I think this solves (and please, correct me if I'm
> wrong - I'm severely jetlagged and was up very late last night, so I may
> not be thinking straight) is that instead of one of us marking a JIRA as
> in progress when someone pops onto the dev list and says they want to
> work on it (which gives much greater visibility to all of us), a
> non-committer can do that themselves.
>
> Maybe I'm simply stupidly biased about this, but I still think that
> driving people here to the dev list for engagement is the healthiest way
> to go.
>
> That said, if you think there's a problem to solve here, lets either
> convince me that I'm wrong, or find another solution - maybe as a group
> think about better ways to track work like this?
>
>
> >
> >>
> >> >
> >> > One of possible solutions is implemented in Apache Geronimo project:
> >> there
> >> > is so called "JIRA contributor" role when the person could modify
> JIRAs
> >> > like
> >> > committers (close/reopen JIRA, modify it's status etc.) but could not
> >> > commit
> >> > the code to the repository.
> >> >
> >> > This role seems intermediate between contributor and committer ones,
> >> some
> >> > kind of "committer kindergarten" :-).
> >> >
> >> > I think that for better processing JIRA issues we could implement
> >> similar
> >> > role in Harmony (or invent something better).
> >> >
> >> >
> >> >
> >> > What do you think?
> >> >
> >>
> >> I'm not a fan.  I want to ensure that people show up here on the dev
> >> list, interact with others, and simply *engage*.  While I haven't
> looked
> >> closely in the last week, my personal impression of things is that we
> >> already have quite a bit of "conversation" on JIRA that never is
> visible
> >> on the dev list, which isn't very good, IMO.
> >
> >
> > I don't think that every problem should be discussed in dev list. For
> > simple
> > cases it's enough to talk in JIRA, but weird cases of course should be
> > discussed in the list and after the discussion the decision should be
> > reflected/implemented in the JIRA.
>
> I guess I don't agree, but in a very particular way - I don't think that
> every problem needs to be discussed, but I think that if a problem needs
> discussion, it should be on the dev list.


I have different opinion :-) - JIRA is not only issues/bugs processing
thing, but also a natural way of discussing particular problems, which may
be not too interesting for a wide community.


> And in my opinion this is what happened today so i don't see any harm
> > adding
> > new roles - this will just help JIRA putting (and having it after that)
> in
> > order.
>
> Which JIRA or issue?


 Recent example: http://issues.apache.org/jira/browse/HARMONY-2383 (should
be "In progress" i think).


geir
>
> >
> > Regards,
> > Mikhail
> >
> > So I guess I'd probably need to understand better what this does for us,
> >> and why it wouldn't have those negative community effects.
> >>
> >> geir
> >>
> >
>

------=_Part_157360_33417353.1166100693287--