> -----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+Maintainers+Per+Component > > -----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 > >
