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