> -----Original Message----- > From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] > Sent: Tuesday, April 02, 2013 3:46 PM > To: dev@cloudstack.apache.org > Subject: RE: [DISCUSS] Don't assign tickets to people when triaging > > > > > -----Original Message----- > > From: Will Chan [mailto:will.c...@citrix.com] > > Sent: Tuesday, April 02, 2013 2:22 PM > > To: dev@cloudstack.apache.org > > Subject: RE: [DISCUSS] Don't assign tickets to people when triaging > > > > I think the purpose of this discussion is that there are people > > currently today that are auto-assigning bugs to individual developers > > of the community. Most of these bugs were assigned for two main reasons. > > > > 1. It was blatantly obvious the bugs stemmed from the feature developer. > > > > - OR - > > > > 2. The bugs were deemed a blocker either by the community, release > > manager, or someone that knows about the issue. > > > > Both of these cases were done partly because of their $dayjobs leaking > > into community. It simply looks like there are hidden agendas when > > these triaging were happening. I think there are obviously ways we > > can get around but to me, it's a burdensome process especially when > > JIRA is a tool that helps our community in organizing our work and > > priorities rather than using the dev@ list. > > > > The second point is that by assigning these bugs, we are effectively > > pushing out anyone that wants to contribute. But as Sebastian has > > already done some legwork, the majority of the bugs are in Unassigned > > state. If someone wants to contribute, there are hundreds of bugs to > participate in. Just go grab one. > > > > Everyone has probably something they are doing besides reading the ML > > every day or doing a search on JIRA. By assigning a bug on JIRA, that > > person gets notified. He can always decline to fix it but at least a > > notification has been sent. I think for the most serious of bugs or > > blocker bugs, anyone in the community should be able to help with the > > triage process. If not for the very least, it helps in notifying the > > developer and effectively pinging the person if they can help assist with > > the > bug or not. > > > > All I am proposing is a more efficient way of dealing with serious > > blocker issues. We can end up losing days of work if we have to wait > > sometimes. I think there are plenty of developers that want to help > > in some way, otherwise, why bother to be on the dev list. However, I > > do know that I cannot search JIRA everyday nor can I read every thread > > that happens here. Someone pinging me via JIRA notifications seems > > like a decent way to be notified. I can always decline to fix the bug. > > > > What do you guys think? Am I the only that wants to make things more > > efficient here? > > > > Will > >
> I take some blame for assigning the defects but intent was to get issues > (mostly > blockers and critical) resolved faster and not to exclude anyone. The issues > were assigned based on our list of component maintainers at [1]. Noah thanks > for clarifying that the triaging may exclude new contributors. > > Can I propose that whoever wants to contribute in fixing defects for a > specific > module add their name as maintainer of that module in component > maintainer list [1]? And we update how to contribute wiki on this process . > > During 4.1 there are a large number of major issues that as community we > ended up not addressing and given that number of unassigned issues is high % > should we consider auto-assign based on the maintainers list? This is still > not > optimal since auto-assign will go to primary maintainer and secondary > maintainers still need to pull in defects but is better than one person > triaging > defects. > > I also wanted to find out how do other projects get through resolving blocker > bugs sooner? > > [1] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Current+Maintainer > s+Per+Component > [Animesh>] Folks I wanted to get your opinion on auto-assignment based on the component maintainers list. We can also create shared issues filters based on components. Folks can subscribe to the filters of interest and receive daily email notification. > > > > -----Original Message----- > > > From: Sebastien Goasguen [mailto:run...@gmail.com] > > > Sent: Tuesday, April 02, 2013 1:56 PM > > > To: dev@cloudstack.apache.org > > > Subject: Re: [DISCUSS] Don't assign tickets to people when triaging > > > > > > > > > On Apr 2, 2013, at 3:21 PM, Noah Slater <nsla...@apache.org> wrote: > > > > > > > Dear community, > > > > > > > > Right now, we have people who are regularly going through JIRA and > > > > triaging tickets. This is totally fantastic, and a very valuable > > > > activity for the project. (So thank you!) But I also notice that > > > > specific individuals are being assigned to the tickets in the process. > > > > > > > > This is a form of "cookie licking". The analogy is that if you > > > > fancy a cookie, but you're too hungry right now, you take a lick > > > > of it so nobody else can touch it. This is an anti-pattern and we > > > > should try to > > > avoid it. > > > > > > > > In general, I would say we should only be assigning a ticket to > > > > ourselves, and we should only be doing that when we actually > > > > intend to sit down and work on it. > > > > > > > > If we have people going through and saying "well, this is clearly > > > > Joe's area" or "this is clearly Fred's area" then that is a great > > > > way to make sure that those areas remain "Joe's area" or "Fred's > > > > area" or > > > whatever. > > > > Which is unhealthy for the project. > > > > > > > > So what I would suggest is that we consider changing the way we > > > > work > > > here. > > > > > > > > Ticket triage might change so that tickets are put on to component > > > > backlogs. And engineers can switch from grabbing tickets of their > > > > "assigned to me" report, and start looking at the "Foo feature > > > > backlog" report instead. Selecting a ticket and assigning it *to > > > > themselves* when they are *starting work on it*. > > > > > > > > (This would then take the ticket off the component backlog. So the > > > > backlog report would only display tickets that were unassigned and > > > > available to > > > > grab.) > > > > > > > > This would mean that all this valuable ticket triage work we're > > > > doing is something that can benefit everyone in the project (not > > > > just people who are already known for their contributions) and > > > > will hopefully open the development workflow to people who are > > > > just starting out with the project, or want to get their toes wet. > > > > > > > > In fact, when someone comes to us and asks "how can I contribute" > > > > we can point them at these backlogs and say "well, just grab a > > > > ticket off one of these queues, assign it to yourself, and start > > > > working on > it!" > > > > We could make use of a "difficulty" field too, so you could sort > > > > by difficulty, and grab one of the "easy", "medium", or "hard" tickets. > > > > > > > > Thoughts? > > > > > > > > -- > > > > NS > > > > > > Hi Noah, I know where you are coming from here, I would just like to > > > point out that a quick JIRA search for Unassgined ticket returns 392 > > > tickets up for grabs (out of 641 open tickets). That's 61% of our > > > total tickets that are Unassigned. > > > > > > In some ways and to keep things simple, anyone should feel free to > > > grab any ticket they think they can work on and hopefully close. No > > > need for buckets, priorities or difficulty rating. Just grab it. > > > > > > > > > -Sebastien > > >
