Bug Triage processes need some improvement and automation...
Alberto Salvia Novella
es20490446e at gmail.com
Tue Nov 5 11:45:30 UTC 2013
I have to (constructively) disagree with these suggestions:
- With the first one because, although it's an improvement, it's just a
*distraction* of what is really important now.
- With the second one because of putting *barriers* in front of
collaboration, one key of success.
- With the point of view in general because forgetting *simplicity*, the
ultimate goal of any system.
El 04/11/13 23:32, AG Restringere escribió:
>
> 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
> <mailto: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 <mailto: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
> <mailto: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/20131105/5e5f3ae7/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2260 bytes
Desc: Firma criptográfica S/MIME
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20131105/5e5f3ae7/attachment.bin>
More information about the Ubuntu-bugsquad
mailing list