Bug Triage processes need some improvement and automation...

[Thomas Ward]

Hey, AG, thanks for splitting this off into a separate discussion.

On Mon, Nov 4, 2013 at 3:54 PM, AG Restringere <ag.restringere at gmail.com> wrote:
> Re-posting my message to this list to create a new thread about Bug Triage
> procedures. I've outlined some ideas that I think would really improve the
> efficiency and clarity of Bug Triage operations.
>
> --------------------------------
>
> 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
> needed or not contribute when a bug actually needed attention and action.
>
> 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 am against this suggestion as it stands, maybe because I do not
understand your reasoning for it or the potential execution of this,
but also because there needs to be made a distinction, in my opinion,
between the role of Bug Triager and the role of "Package Fixer" (for
lack of a better term, this would be someone with the package
knowledge and development knowledge to fix the bugs once they're
"Triaged").

A triager may help get the bug from New to Triaged or New to
Confirmed, but ultimately someone with developer knowledge of the
package, or the knowledge to patch the package, is going to be the one
the bug is "assigned" to for the work item.  As well, a single
individiual triager may have to collaborate with other triagers in
order to get the package to the "Triaged" state.  I myself have
collaborated with other bug controllers and bug triagers in order to
get bugs moved along to a point where a developer can work on the
bugs, and in most cases, I quite like that collaboration.  That
collaboration would then, in a sense, mean that all the triagers who
have collaborated on it are "owners" of the bug for a triaging sense.
Assigning one "triage owner" for a bug defeats the general idea of
that collaboration of which myself and others are so fond of.

Also, unless you're proposing changing the bug system to have an
additional "Triage Owner" role and field on the bug and restricting
"Triage Owner" to bug controllers who actually have the access that
Bug Squad does not have (i.e. to set the "Triaged" state and the bug
importance, as well as other bug-control specific tasks), the
"Assigned To" field on bugs is used to identify who the work on fixing
the bug is assigned to, not the triager.  I still stand by this,
because as one of the people primarily working on the nginx package
now, I have seen people assign themselves to bugs and fix them, or
assign themselves, and then hand me the work later, and reassigning it
to me as the person who will fix it or SRU it or whatever.

>
> 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.

I'm confused here.  As a Bug Squad member, I have received exactly 0
email addresses for subscribed bugs, in that the Bug Squad isn't
subscribed to any bugs by default.  As a Bug Control member, I see
some crash bug data for which bugcontrol is subscribed to, or is a
member of one of the teams subscribed.  In comparison with the
packages' bugs which I am specifically subscribed to, I've seen very
few bug-control subscribed bug stuff, so I'm a little confused with
this modification or concern.

>
> 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 the feedback and ideas above can be tested in some form and
> implemented.
>
> Best regards,
> AG
>
> --
> Ubuntu-bugsquad mailing list
> Ubuntu-bugsquad at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad
>

------
Thomas