A proposal to combine quality and bugsquad teams

[AG Restringere]

Thomas,

Thank you for the information. I was previously unaware that they were two
separate groups. In that case where should I direct this feedback to
improve Bug Triage processes and what are the next steps I should take?

Best regards,
AG


On Mon, Nov 4, 2013 at 3:19 PM, Thomas Ward <teward at trekweb.org> wrote:

> Ummm... I may be nitpicking but this is important... I think you're
> confusing Bug Squad with Bug Control, AG...
>
> In my discussions with Nicholas on IRC, we discussed the separation of Bug
> Squad and Bug Control.  Bug Squad has no specific rules to be a member.  It
> also does not give any special bug permissions to an individual.
>
> Bug Control is a separate group with a specific application procedure and
> has more permissions with bugs.  Given that, I had mentioned with Nicholas
> about the distinction and it was generally agreed that Bug Control would be
> left alone and separate from this 'merging' of Bug Squad and QA.
>
> Unless I missed further discussion on this, which would probably have
> landed on the Bug Control mailing list, that 'general understanding' still
> stood strong...
>
> (I want to make sure that you understand the distinction there, AG, that
> Bug Squad and Bug Control are different groups all bound to the same
> trialling rules, but with substantially different permission sets and
> application procedures.)
>
> On Nov 4, 2013, at 2:03 PM, AG Restringere <ag.restringere at gmail.com>
> wrote:
>
> 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
>>
>
> --
> Ubuntu-quality mailing list
> Ubuntu-quality at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20131104/8127440f/attachment-0001.html>