<div dir="ltr">Sean,<div><br></div><div>This sounds amazing and Swift could definitely use some [automated] assistance here.  It would help if you could throw out a WIP somewhere.</div><div><br></div><div>First thought that comes to mind tho .... storyboard.o.o :\</div><div><br></div><div>-Clay<br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 23, 2017 at 9:52 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The Nova bug backlog is just over 800 open bugs, which while<br>
historically not terrible, remains too large to be collectively usable<br>
to figure out where things stand. We've had a few recent issues where we<br>
just happened to discover upgrade bugs filed 4 months ago that needed<br>
fixes and backports.<br>
<br>
Historically we've tried to just solve the bug backlog with volunteers.<br>
We've had many a brave person dive into here, and burn out after 4 - 6<br>
months. And we're currently without a bug lead. Having done a big giant<br>
purge in the past<br>
(<a href="http://lists.openstack.org/pipermail/openstack-dev/2014-September/046517.html" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>pipermail/openstack-dev/2014-<wbr>September/046517.html</a>)<br>
I know how daunting this all can be.<br>
<br>
I don't think that people can currently solve the bug triage problem at<br>
the current workload that it creates. We've got to reduce the smart<br>
human part of that workload.<br>
<br>
But, I think that we can also learn some lessons from what active github<br>
projects do.<br>
<br>
#1 Bot away bad states<br>
<br>
There are known bad states of bugs - In Progress with no open patch,<br>
Assigned but not In Progress. We can just bot these away with scripts.<br>
Even better would be to react immediately on bugs like those, that helps<br>
to train folks how to use our workflow. I've got some starter scripts<br>
for this up at - <a href="https://github.com/sdague/nova-bug-tools" rel="noreferrer" target="_blank">https://github.com/sdague/<wbr>nova-bug-tools</a><br>
<br>
#2 Use tag based workflow<br>
<br>
One lesson from github projects, is the github tracker has no workflow.<br>
Issues are openned or closed. Workflow has to be invented by every team<br>
based on a set of tags. Sometimes that's annoying, but often times it's<br>
super handy, because it allows the tracker to change workflows and not<br>
try to change the meaning of things like "Confirmed vs. Triaged" in your<br>
mind.<br>
<br>
We can probably tag for information we know we need at lot easier. I'm<br>
considering something like<br>
<br>
* needs.system-version<br>
* needs.openstack-version<br>
* needs.logs<br>
* needs.subteam-feedback<br>
* has.system-version<br>
* has.openstack-version<br>
* has.reproduce<br>
<br>
Some of these a bot can process the text on and tell if that info was<br>
provided, and comment how to provide the updated info. Some of this<br>
would be human, but with official tags, it would probably help.<br>
<br>
#3 machine assisted functional tagging<br>
<br>
I'm playing around with some things that might be useful in mapping new<br>
bugs into existing functional buckets like: libvirt, volumes, etc. We'll<br>
see how useful it ends up being.<br>
<br>
#4 reporting on smaller slices<br>
<br>
Build some tooling to report on the status and change over time of bugs<br>
under various tags. This will help visualize how we are doing<br>
(hopefully) and where the biggest piles of issues are.<br>
<br>
The intent is the normal unit of interaction would be one of these<br>
smaller piles. Be they the 76 libvirt bugs, 61 volumes bugs, or 36<br>
vmware bugs. It would also highlight the rates of change in these piles,<br>
and what's getting attention and what is not.<br>
<br>
<br>
This is going to be kind of an ongoing experiment, but as we currently<br>
have no one spear heading bug triage, it seemed like a good time to try<br>
this out.<br>
<br>
Comments and other suggestions are welcomed. The tooling will have the<br>
nova flow in mind, but I'm trying to make it so it takes a project name<br>
as params on all the scripts, so anyone can use it. It's a little hack<br>
and slash right now to discover what the right patterns are.<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</font></span></blockquote></div><br></div></div></div>