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