>> >>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.
7-8 days is a huge time lost. I was suggesting that this to be 3 days. Let other community members chime in too. > >> >>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. >> >>> >> >
