<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 18, 2014 at 11:48 PM, Flavio Percoco <span dir="ltr"><<a href="mailto:flavio@redhat.com" target="_blank">flavio@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 18/11/14 14:45 -0800, Joe Gordon wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Tue, Nov 18, 2014 at 10:58 AM, Clint Byrum <<a href="mailto:clint@fewbar.com" target="_blank">clint@fewbar.com</a>> wrote:<br>
<br>
Excerpts from Flavio Percoco's message of 2014-11-17 08:46:19 -0800:<br>
> Greetings,<br>
><br>
> Regardless of how big/small bugs backlog is for each project, I<br>
> believe this is a common, annoying and difficult problem. At the oslo<br>
> meeting today, we're talking about how to address our bug triage<br>
> process and I proposed something that I've seen done in other<br>
> communities (rust-language [0]) that I consider useful and a good<br>
> option for OpenStack too.<br>
><br>
> The process consist in a bot that sends an email to every *volunteer*<br>
> with 10 bugs to review/triage for the week. Each volunteer follows the<br>
> triage standards, applies tags and provides information on whether the<br>
> bug is still valid or not. The volunteer doesn't have to fix the bug,<br>
> just triage it.<br>
><br>
> In openstack, we could have a job that does this and then have people<br>
> from each team volunteer to help with triage. The benefits I see are:<br>
><br>
> * Interested folks don't have to go through the list and filter the<br>
> bugs they want to triage. The bot should be smart enough to pick the<br>
> oldest, most critical, etc.<br>
><br>
> * It's a totally opt-in process and volunteers can obviously ignore<br>
> emails if they don't have time that week.<br>
><br>
> * It helps scaling out the triage process without poking people around<br>
> and without having to do a "call for volunteers" every meeting/cycle/etc<br>
><br>
> The above doesn't solve the problme completely but just like reviews,<br>
> it'd be an optional, completely opt-in process that people can sign up<br>
> for.<br>
><br>
<br>
My experience in Ubuntu, where we encouraged non-developers to triage<br>
bugs, was that non-developers often ask the wrong questions and<br>
sometimes even harm the process by putting something in the wrong<br>
priority or state because of a lack of deep understanding.<br>
<br>
Triage in a hospital is done by experienced nurses and doctors working<br>
together, not "triagers". This is because it may not always be obvious<br>
to somebody just how important a problem is. We have the same set of<br>
problems. The most important thing is that developers see it as an<br>
important task and take part. New volunteers should be getting involved<br>
at every level, not just bug triage.<br>
<br>
<br>
++, nice analogy.<br>
<br>
Another problem I have seen, is we need to constantly re-triage bugs, as just<br>
because a bug was marked as confirmed 6 months ago doesn't mean it is still<br>
valid.<br>
</blockquote>
<br></div></div>
Ideally, the script will take care of this. Bugs that haven't been<br>
update for more than N months will fall into the "to-triage" pool for<br>
re-triage.<br></blockquote><div><br></div><div>I am willing to sign up and give this a try.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Flavio<div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
I think the best approach to this, like reviews, is to have a place<br>
where users can go to drive the triage workload to 0. For instance, the<br>
ubuntu server team had this report for triage:<br>
<br>
<a href="http://reqorts.qa.ubuntu.com/reports/ubuntu-server/triage-report.html" target="_blank">http://reqorts.qa.ubuntu.com/<u></u>reports/ubuntu-server/triage-<u></u>report.html</a><br>
<br>
Sadly, it looks like they're overwhelmed or have abandoned the effort<br>
(I hope this doesn't say something about Ubuntu server itself..), but<br>
the basic process was to move bugs off these lists. I'm sure if we ask<br>
nice the author of that code will share it with us and we could adapt<br>
it for OpenStack projects.<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
<br>
<br>
</blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
@flaper87<br>
Flavio Percoco<br>
</font></span><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>