[openstack-dev] [all] Scale out bug-triage by making it easier for people to contribute

Flavio Percoco flavio at redhat.com
Wed Nov 19 07:48:16 UTC 2014


On 18/11/14 14:45 -0800, Joe Gordon wrote:
>
>
>On Tue, Nov 18, 2014 at 10:58 AM, Clint Byrum <clint at fewbar.com> 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.
>
>
>++, nice analogy.
>
>Another problem I have seen, is we need to constantly re-triage bugs, as just
>because a bug was marked as confirmed 6 months ago doesn't mean it is still
>valid.

Ideally, the script will take care of this. Bugs that haven't been
update for more than N months will fall into the "to-triage" pool for
re-triage.

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

>_______________________________________________
>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/f33cd38e/attachment.pgp>


More information about the OpenStack-dev mailing list