On 06/26/2017 04:49 AM, Sylvain Bauza wrote: > > > Le 23/06/2017 18:52, Sean Dague a écrit : >> 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. >> > > Thanks for sharing ideas, Sean. > >> 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 >> > > Sometimes, I had no idea why but I noticed the Gerrit hook not working > (ie. amending the Launchpad bug with the Gerrit URL) so some of the bugs > I was looking for were actively being worked on (and I had the same > experience myself although my commit msg was pretty correctly marked AFAIR). > > Either way, what you propose sounds reasonable to me. If you care about > fixing a bug by putting yourself owner of that bug, that also means you > engage yourself on a resolution sooner than later (even if I do fail > applying that to myself...). > >> #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. >> > > The tags you propose seem to me related to an "Incomplete" vs. > "Confirmed" state of the bug. > > If I'm not able to triage the bug because I'm missing information like > the release version or more logs, I put the bug as Incomplete. > I could add those tags, but I don't see where a programmatical approach > could help us.
We always want that information, and the odds of us getting it from a user decline over time. When we end up looking at bugs that are year old, it becomes a big guessing game on their relevancy. The theory here is that tags like that would be applied by a bot immediately after the bug is filed. Catching the owner within 5 minutes of their bug filing with a response which is "we need the following" means we should get a pretty decent attach rate on that information. And then you don't have to spend 10 minutes of real human time realizing that you really need that before moving forward. -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