A proposal to combine quality and bugsquad teams

[Alberto Salvia Novella]

What I find useful is having simple information in the wiki about how to 
find relevant bugs by using the advance search in Launchpad.


El 04/11/13 20:03, AG Restringere escribió:
> 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 <mailto: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
>     <mailto: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/161d439f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2260 bytes
Desc: Firma criptogr??fica S/MIME
URL: <https://lists.ubuntu.com/archives/ubuntu-quality/attachments/20131104/161d439f/attachment.bin>