A proposal to combine quality and bugsquad teams

[AG Restringere]

Thomas,

Okay, I'll create a separate subject and thread for this...thanks...

Best,
AG


On Mon, Nov 4, 2013 at 3:43 PM, Thomas Ward <teward at ubuntu.com> wrote:

> AG,
>
> You are correct in proposing triage procedures here to the Bug Squad
> mailing list, but that should be made as a separate thread, in my
> opinion.  As it stands, the bug squad and QA are still separate right
> now, but ultimately any changes in triage procedure affect every group
> working with Ubuntu bugs, including the Server Team.
>
> Bug Control and Bug Squad work collectively on triage procedures, and
> the people in charge of bug triage (namely the bug god, Brian) do look
> at recommendations, so I recommend splitting your suggestions off the
> chain for the QA/BugSquad merger discussion and into its own thread on
> the bugsquad mailing list for now.
>
> -----
> Thomas
>
> On Mon, Nov 4, 2013 at 3:40 PM, AG Restringere <ag.restringere at gmail.com>
> wrote:
> > 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/c7bedbdf/attachment-0001.html>