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. <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>> Mikhail Markov wrote:
>> > On 12/14/06, Geir Magnusson Jr. <[EMAIL PROTECTED]> 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
>> >>
>> >
>>
>
