+1 to Abhi's suggestion.
> -----Original Message-----
> From: Abhinandan Prateek [mailto:abhinandan.prat...@citrix.com]
> Sent: Thursday, April 11, 2013 8:40 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Don't assign tickets to people when triaging
>
>
>
> 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.
>
> >
