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 <[email protected]> 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 <[email protected]> > 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 < > [email protected]> 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 >> [email protected] >> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad >> > > -- > Ubuntu-quality mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality > >
-- Ubuntu-quality mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
