Open Stack

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