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
>>
>
