On the 0x23F day of Apache Harmony Vladimir Beliaev wrote: > 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...
In that case, I would have written to the mailing list: "hello, guys, I am a VM threading expert, what are the hottest tasks for me?" We have 1 threading item in the "Core VM Development tasks" that I can find. Quite simple and fast. > 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 > >> >> > >> > > >> > > > > -- Egor Pasko
