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