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 <[email protected]> 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 <[email protected]> > 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 <[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
