Open Stack

On 18/11/14 10:58 -0800, Clint Byrum wrote:
>Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800:
>> Greetings,
>>
>> Regardless of how big/small bugs backlog is for each project, I
>> believe this is a common, annoying and difficult problem. At the oslo
>> meeting today, we're talking about how to address our bug triage
>> process and I proposed something that I've seen done in other
>> communities (rust-language [0]) that I consider useful and a good
>> option for OpenStack too.
>>
>> The process consist in a bot that sends an email to every *volunteer*
>> with 10 bugs to review/triage for the week. Each volunteer follows the
>> triage standards, applies tags and provides information on whether the
>> bug is still valid or not. The volunteer doesn't have to fix the bug,
>> just triage it.
>>
>> In openstack, we could have a job that does this and then have people
>> from each team volunteer to help with triage. The benefits I see are:
>>
>> * Interested folks don't have to go through the list and filter the
>> bugs they want to triage. The bot should be smart enough to pick the
>> oldest, most critical, etc.
>>
>> * It's a totally opt-in process and volunteers can obviously ignore
>> emails if they don't have time that week.
>>
>> * It helps scaling out the triage process without poking people around
>> and without having to do a "call for volunteers" every meeting/cycle/etc
>>
>> The above doesn't solve the problme completely but just like reviews,
>> it'd be an optional, completely opt-in process that people can sign up
>> for.
>>
>
>My experience in Ubuntu, where we encouraged non-developers to triage
>bugs, was that non-developers often ask the wrong questions and
>sometimes even harm the process by putting something in the wrong
>priority or state because of a lack of deep understanding.
>
>Triage in a hospital is done by experienced nurses and doctors working
>together, not "triagers". This is because it may not always be obvious
>to somebody just how important a problem is. We have the same set of
>problems. The most important thing is that developers see it as an
>important task and take part. New volunteers should be getting involved
>at every level, not just bug triage.

Heh, great analogy.

The idea is not to encourage developers of the project to participate
actively in the triage process. I'd even say that the final goal is to
make the triage process somehow easier for people willing to do so.

FWIW, bug triage - along side with code reviews - is a very good way
to get started in projects. People triaging bugs should go to the team
asking for guidance when they have no clue what to do with a bug (or
they can just skip it).

I know the above is full of hopes and idealisms but I do think people
willing to help will sign up and they will do the best they can to
help in the process. It may end up being just devs of the project but
that's already a good step forward.

Triaging 10 bugs most of the time doesn't take more than 30mins and I
think it's doable in a week.

Flavio

>
>I think the best approach to this, like reviews, is to have a place
>where users can go to drive the triage workload to 0. For instance, the
>ubuntu server team had this report for triage:
>
>http://reqorts.qa.ubuntu.com/reports/ubuntu-server/triage-report.html
>
>Sadly, it looks like they're overwhelmed or have abandoned the effort
>(I hope this doesn't say something about Ubuntu server itself..), but
>the basic process was to move bugs off these lists. I'm sure if we ask
>nice the author of that code will share it with us and we could adapt
>it for OpenStack projects.
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/2ff3670d/attachment.pgp>