On 18 Nov 2014 18:59, "Clint Byrum" <cl...@fewbar.com> wrote: <SNIP> > I think the best approach to this, like reviews, is to have a place > where users can go to drive the triage workload to 0. For instance, the > ubuntu server team had this report for triage: > >http://reqorts.qa.ubuntu.com/reports/ubuntu-server/triage-report.html > > Sadly, it looks like they're overwhelmed or have abandoned the effort > (I hope this doesn't say something about Ubuntu server itself..), but > the basic process was to move bugs off these lists. I'm sure if we ask > nice the author of that code will share it with us and we could adapt > it for OpenStack projects. >
I agree that this approach can be quite successful. I think I authored the original report you link to, originally for my own use to track the queue and then later shared it with the team to introduce the practice you refer to. It was made prettier, and perhaps richer by someone else. We had a rota of 2 people per day who were tasked with initial triage of all incoming bugs. If they were on the same timezone, many found it easier to start from opposite ends of the list. This meant that the queue was kept to a manageable list and all new bugs were initially looked at promptly. Once you have this process in place, keeping the triage list empty is low effort. I don't know why it seems to no longer be used, perhaps a switch in priorities? I don't know. The report generator is here I think: http://bazaar.launchpad.net/~ubuntu-reports-dev/ubuntu-reports/trunk/view/head:/server/reportgenerator.py -- Kind Regards, Dave Walker
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
