Bug Triage processes need some improvement and automation...

[AG Restringere]

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


Sorry, I didn't understand just how specific the usage of the term
"Assigned To:" is in Ubuntu.  Given that in Ubuntu the "Assigned To:"
term/status is used specifically for Developers and Packagers that will fix
the bug then I am not using a correct term.  In that case a new term is
needed to avoid confusion.  The better term would be a "Managed By:" status
because the Bug Triage person is managing the bug but not fixing it. This
would work in a similar way to "Assigned To:" but it would apply to Bug
Squad and Bug Control members and not Developers or Packagers.  The new
status would make it crystal clear which Bug Squad/Control member is
managing the bug and whether it's being actively managed. The Launchpad
bug-menu and search filters would have to be modified to accommodate this
and only Bug Squad/Control members could have permissions over it is so the
public wouldn't use it by mistake.


> Assigning one "triage owner" for a bug defeats the general idea of
> that collaboration of which myself and others are so fond of.
>

Collaboration could still be possible but there would be a more systematic
approach.  Just because a bug is "Managed By:" a single Bug Triage person
and doesn't mean that they can't ask other Bug Triage members for help,
advice, to look at a log, agree that a two bugs are duplicates, etc...It
just means that in the end of the day one single Bug Triage person is
making comments on the bug and that one person is responsible for triaging
it. Just take the number of open non-triaged bugs and divide them by the
number of Bug Triage "staff" currently available, you'll most likely get a
very large quantity.  Given the high level of interest that OEM's and games
developers have in Ubuntu you'll probably want to ensure Bug Triage is as
fast as possible.  Unfortunately Bug Triage is a limited resource, the team
only has so much time to work on a large number of bugs, so you'll have
streamline the process to make it faster.

I'm confused here...(...)...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.


Then this is something team specific that I will have to bring to the
attention of the Ubuntu-X team and I'll have to see if there's a way they
can tone down their bug volume or if I can turn off my bug-mail for that
specific team.

All in all I don't know how "workable" these suggestions are at this point
and it is certainly a long-term process of improvement that will have to be
taken in small incremental stage. The most important item in my view is to
implement the "Managed By:" tool/status and the "one bug one Triager"
system.

Best regards,
AG


On Mon, Nov 4, 2013 at 4:15 PM, Thomas Ward <teward at ubuntu.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20131104/3194597f/attachment.html>