cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinandan Prateek <Abhinandan.Prat...@citrix.com>
Subject Re: [DISCUSS] Don't assign tickets to people when triaging
Date Thu, 11 Apr 2013 10:22:01 GMT

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


Mime
View raw message