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 gcjhd-harmony-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@harmony.apache.org
From: Vladimir Beliaev <vladimir.k.beliaev@gmail.com>
Subject: Re: [general] Wise JIRA processing
Date: Thu, 14 Dec 2006 16:59:08 +0300
Lines: 222
Message-ID: <458158AC.2080906@gmail.com>
References: <51abf0750612132224x6f087cbbwab1f99f9d664aaf2@mail.gmail.com>
	 <458106C2.9030606@pobox.com>
	 <51abf0750612140058w1b31b8a4i70aadfa1dbe026d5@mail.gmail.com>
	 <45811479.7060204@pobox.com>
 <51abf0750612140451g3a1d71bq6f3b675169cc8080@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Thunderbird 1.5.0.7 (Windows/20060909)
In-Reply-To: <51abf0750612140451g3a1d71bq6f3b675169cc8080@mail.gmail.com>
Sender: news <news@sea.gmane.org>

Hello,

interesting point... I'm looking to JIRA from contributor prospective 
and I can't get idea from it what is going on with bugs.

AFAIGot the existing solution here is: each contributor should write to 
dev-list the question like "what is going on" and "what can I work on"? 
If this is true, then you can skip later reading...

Let me explain:

About "subcomponents": suppose, I'm VM threading expect (just suppose - 
I'm not actually) and I want to join Harmony (as contributor). I'm 
looking into JIRA and see ... h-m-m ... 148 issues... Ok, let's use 
filtering - I use 'thread' in search pattern - wau, 105 issues found and 
most of them has nothing to do with threading... I better do not look 
through all 105 JIRAs and give up...

About "assigments": suppose I got the list of thread related issues 
(some way - say, we agreed to add [thread] suffix after [drlvm] prefix 
and "JIRA ontributor" regularly re-checks all JIRAs to update summary 
acordingly). The number of 'thread' JIRAs is pretty great (say 30). Non 
of these issues is assigned (no committer has taken it). Ok, I want to 
work on one of them. AFAIK the way of "getting" JIRA is to write "I take 
it" in its comment. I start looking through JIRAs and finding "I take 
it" in each of them before I find "non-taken" one at the end of list - 
something to make any guy distracted.

Base on above I believe we should do something with existing JIRAs - 
probably Mikhail proposal (about "JIRA ontributor") is one which worth 
implementing.

Thanks
Vladimir

Mikhail Markov wrote:
> 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
>> >>
>> >
>>
>