harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [general] Wise JIRA processing
Date Thu, 14 Dec 2006 09:08:09 GMT

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.

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.

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


> 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

View raw message