So let me start off with I agree in principle with what Noah is talking about here. Cookie licking is an anti-pattern that we should reject as a community. However, I disagree the solution or even what is perceived as cookie licking.
We established a while ago as a community that we follow a Jira workflow in handling bugs. In that process, a bug is Open until it goes to "In Progress". We can simply tweak our expectations on this workflow to achieve exactly the desired effects. - Assign bugs does not mean you own it, even if you assign it to yourself doesn't mean you own it. - No one owns a bug until the person assigned changed it to In Progress (not licked til this stage) - Before a bug goes into In Progress, anyone can grab it. By doing this we allow people who can help in prioritizing the bugs to assign bugs without going through another layer of negotiation. Assigning bugs merely means asking the question "can you work on it". This would be much more efficient way of doing things. I also think that we can setup public filters that people can use to find bugs they can work on. In the filter, it doesn't look at who the bug is assigned to. Just whether the bug is open or not. --Alex > -----Original Message----- > From: Noah Slater [mailto:nsla...@apache.org] > Sent: Tuesday, April 2, 2013 12:21 PM > To: dev@cloudstack.apache.org > Subject: [DISCUSS] Don't assign tickets to people when triaging > > 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
