Bug Triage processes need some improvement and automation...

[Brian Murray]

On Mon, Nov 04, 2013 at 03:54:55PM -0500, AG Restringere wrote:
> Re-posting my message to this list to create a new thread about Bug Triage
> procedures. I've outlined some ideas that I think would really improve the
> efficiency and clarity of Bug Triage operations.
> 
> --------------------------------
> 
> In my experience in - when I dabbled in some bug control work as part of
> the Ubuntu-X team - the Bug Triage process is still very tedious and lacks
> sufficient automation. Most of the time and effort I spent doing bug
> control work was spent browsing Launchpad and reading through hundreds of
> bug-emails in order to find bugs to work on.  Most of my time was spent
> searching for bugs but very little of my time was spent actively working on
> bugs and being productive.  Also, many times I saw bugs that had comments
> from Bug Control members but it was never clear who was working on the bug
> or what they wanted to do with it.  This often lead me to add comments when
> they weren't needed or not contribute when a bug actually needed attention
> and action.

What types of bugs did you have difficultly searching for?

> Modifications I would make to the Bug Triage process:
> 
> 1. Assignment and eliminating redundancy:
> 
> When a Bug Triager begins working on a bug they should assign themselves to
> the bug on Launchpad if they intend to actively work on it.  Only one Bug
> Triage member should be assigned and actively working on a bug at any given
> time and they should effectively "own" that bug and be responsible for it.
>  The only other people who should be working on that specific bug should be
> Reporters, Testers and Developers.  Assignment would help other Bug Triage
> people to know "this bug is actively owned by another member" and know to
> move on to other bugs and leave that one alone.  It would be even better if
> Launchpad could filter out the bugs that were actively assigned to Bug
> Control members so people could find those that nobody was working on and
> needed attention.  Sufficient criteria for finding new bugs could be as
> simple as "Confirmed"+"Unassigned".

In the scenario where a Bug Triager is working on a bug in what state is
the bug report?

If it is missing information then it should have a status of Incomplete
and having the bug assigned would prevent it from expiring.  Bug
expiration is a useful thing because we frequently have bug reporter who
have a "fire and forget" attitude and do not respond to questions for
more information.

> 2. Email volume reduction:
> 
> Bug Triage members should only receive emails about bugs they're actively
> assigned to.  It's really time consuming to sort through hundreds of
> bug-mails that involve bugs that are not relevant to ones currently being
> worked on.  This applies to all roles such as Testers, Reporters and others
> as well.  The only general emails that should be received should be from
> the discussion or developer mailing lists.

Launchpad generally sends e-mails to people assigned to or subscribed to
bug reports.  If someone is receiving a high volume of email this is due
to a subscription that they, or a team of which they are a member, have
setup.  So not everyone has to receive hundreds of bug mails.

This wiki page is really helpful for filtering Launchpad mail:

https://wiki.ubuntu.com/Bugs/HowToFilter

> 3. Auto-assignment process queue:
> 
> Similar to a tech-support ticket system the next step in this process would
> be to introduce a process queue with auto-assignment of bugs to Bug Triage
> members.  I don't know how this would work but some status change in the
> bug would have to trigger it's submission it into the process queue such as
> reaching a Confirmed status or increased Reporter activity at some
> threshold level. The distribution of the bugs would have to take into
> account the work-load of the Bug Triage members and distribute them evenly
> but perhaps that's a bit too complicated to do in code. Maybe random
> assignment would be better or it could based on the package selection
> preferences of individual members. Perhaps there could even be some senior
> Bug Control members who would manually assign the bugs from the queue.
>  This would eliminate the need for Bug Triage members to even need to go to
> Launchpad to search for bugs unless they're doing some extra research.
>  Bugs would be sent to them via email automatically when they're ready to
> be triaged and auto-assigned without any extra steps needed.

I think that given the quantity of bugs reported on a daily basis and
the number of people actively triaging bug reports we'd quickly end up
overwhelmed and demotivated.  I believe we talked about this idea once
before and I'd suggested trying the process of assigning bugs to
yourself as an experiment.  Did you end up doing that?

--
Brian Murray
Ubuntu Bug Master