Open Stack

On 18 Nov 2014 18:59, "Clint Byrum" <clint at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141119/7c218d11/attachment.html>