+1 with slight modifications :) On 11/04/13 8:39 AM, "Abhinandan Prateek" <abhinandan.prat...@citrix.com> wrote:
> > >On 10/04/13 8:57 PM, "Joe Brockmeier" <j...@zonker.net> wrote: > >>On Wed, Apr 10, 2013, at 02:35 AM, Abhinandan Prateek wrote: >>> I think if you were wrongly assigned bug that you did not want to work >>>on >>> just spit it in the mailing list and you will not be guilty of cookie >>> licking. >>> >>> Given the huge number bugs lets focus on how to reduce that pile >>>instead >>> of raking up non issues. >> >>It's not a non-issue. When people see bugs assigned to a person, they're >>less likely to go ahead and take it. > > >I will start with an example: A critical bug (CLOUDSTACK-1941) that is >blocking a release (4.1) is not picked up by any community member for 5 >days ! >The reason being that it is a UI issue but not that clear from the desc, >the nature of the bug is known after someone spends time on it. > >Now is it wrong to ask the community members who have expertise on UI to >fix it, in a bid to help Chip get the release out ? > >A set of guidelines are necessary so that this whole confusion about bugs >getting assigned is cleared up. I will start by proposing some simple >rules: > >1. Never assign bugs that are not critical or blocker unless they meet any >of the below condition. Never would be too lenient. Maybe assign it after 7-8 days since they don't need immediate attention. > >2. Assign a bug that is open for more than 3 days and none of the >community member has shown interest in picking it up. This period can vary >depending on how close a branch where bug is noted is close to a release. A community member should always have an interest area within CS and he/she subscribes to it. IF a bug is opened in that area he/she should be notified (yeah we can set rules in our email client). > >3. Assign or request to community for picking up a bug if it is blocking >the work that a community member may be working on. > >Do add or amend so that we clear up process around this issue. > > >> >> >>I think we need to find a middle path where: >> >>* Everyone is pro-active in reviewing bugs that are in their area, and >>not depending on a having bugs assigned before they work on them. >> >>* We don't have a ridiculous number of bugs assigned to people where >>they may not get to those bugs for weeks - when someone else might >>conceivably work on them, but be put off because they think "Oh, Random >>J. Programmer already has that." >> >>* We can assign bugs when it does make sense, without there being an >>absolute rule against assigning bugs to people when common sense >>dictates otherwise. > >I just tried to extract this part of the email as a set of rules above. > >> >
