A proposal to combine quality and bugsquad teams

[AG Restringere]

Hello Q/A and Bug Control teams,

This is the first time I post to this list so hello!

Because Bug Control is being restructured I was hoping that some of my
ideas and experiences could find their way into the blueprint and be
discussed at the next UDS:

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 necessary or not contribute when a bug actually needed
attention.  As a result I don't think the current process as it stands
should be re-introduced into the new combined Q/A and Bug Control as is i
without some modifications.

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".  I think this sort of assignment scheme
makes sense given that the new Bug Control restructuring effort involves
making roles very specific and eliminating redundancy.

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.

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.

Conclusion:

If the above steps were implemented or some equivalent processes I think
the Bug Triage would be streamlined, eliminate redundancy and get faster
turn-around times.  Bug Triage members would be more focused and
successful. Newer Bug Triage members would be able to be "plugged in" to a
standardized process and this would improve retention because people would
see results faster with less effort.

Hopefully my feedback and comments had some value and will be considered
for the upcoming changes to the Bug Control team and it's processes. If
there are any other ways I can help the newly combined Q/A and Bug Control
please let me know.  Thank you for your time and attention.

Best regards,
AG







On Wed, Oct 30, 2013 at 2:50 PM, Nicholas Skaggs <
nicholas.skaggs at canonical.com> wrote:

> Thanks to everyone for the feedback. Given the positive responses I would
> like to move forward with the change. To help facilitate all the little
> odds and ends of transitioning, I've created a blueprint for the upcoming
> UDS:
>
> https://blueprints.launchpad.net/ubuntu/+spec/community-
> 1311-quality-bugsquad
>
> We'll discuss how to transition lp teams, responsibilities, documentation
> and wiki issues, etc. Please add anything that needs to be discussed to the
> whiteboard on the blueprint. Seriously, have at it! Edit away!
>
> In the interim, please feel free to participate in bugsquad and quality
> activities as a member of either team :-) I know several bugsquadders have
> introduced themselves to the quality list -- thank you!
>
> Nicholas
>
>
> --
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20131104/7abf60e5/attachment.html>