<div dir="ltr">Hello Q/A and Bug Control teams,<div><br></div><div>This is the first time I post to this list so hello! </div><div><br></div><div>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:</div>
<div><br></div><div>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. </div>
<div><br></div><div>Modifications I would make to the Bug Triage process:</div><div><br></div><div>1. Assignment and eliminating redundancy: </div><div><br></div><div>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.</div>
<div><br></div><div>2. Email volume reduction: </div><div><br></div><div>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.</div>
<div><br></div><div>3. Auto-assignment process queue:</div><div><br></div><div>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.</div>
<div><br></div><div>Conclusion:</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Best regards,</div><div>AG </div><div><br></div><div><br></div><div> <br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Oct 30, 2013 at 2:50 PM, Nicholas Skaggs <span dir="ltr"><<a href="mailto:nicholas.skaggs@canonical.com" target="_blank">nicholas.skaggs@canonical.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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:<br>
<br>
<a href="https://blueprints.launchpad.net/ubuntu/+spec/community-1311-quality-bugsquad" target="_blank">https://blueprints.launchpad.<u></u>net/ubuntu/+spec/community-<u></u>1311-quality-bugsquad</a><br>
<br>
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!<br>
<br>
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!<span class="HOEnZb"><font color="#888888"><br>
<br>
Nicholas</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
-- <br>
Ubuntu-bugsquad mailing list<br>
<a href="mailto:Ubuntu-bugsquad@lists.ubuntu.com" target="_blank">Ubuntu-bugsquad@lists.ubuntu.<u></u>com</a><br>
<a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad" target="_blank">https://lists.ubuntu.com/<u></u>mailman/listinfo/ubuntu-<u></u>bugsquad</a><br>
</div></div></blockquote></div><br></div>