<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">I have to (constructively) disagree with these suggestions:</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">- With the first one because, although it's an improvement, it's just a </span><b style="font-family:arial,sans-serif;font-size:13px">distraction</b><span style="font-family:arial,sans-serif;font-size:13px"> of what is really important now.<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">- With the second one because of putting </span><b style="font-family:arial,sans-serif;font-size:13px">barriers</b><span style="font-family:arial,sans-serif;font-size:13px"> in front of collaboration, one key of success.<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">- With the point of view in general because forgetting </span><b style="font-family:arial,sans-serif;font-size:13px">simplicity</b><span style="font-family:arial,sans-serif;font-size:13px">, the ultimate goal of any system.</span></blockquote>
<div><br></div><div>Got it, understood, you don't want to alter the current processes, adding a "Managed By:" field and using it doesn't mean altering processes, it just provides additional information that reduces some uncertainty.</div>
<div><br></div><div>Let's look at this recent bug I submitted to Launchpad:</div><div><a href="https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304" target="_blank">https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1221304</a><br>
</div><div><br></div><div>Right now there are some bug comments from Stephen M. Webb (Bregma) indicating some sort of triage activity but there's nothing on the bug report letting me know if it's being actively triaged and by who. This information should be clearly displayed on the bug report header. Here's a quick mock-up of that clearly describes what I would like to see on a bug report.</div>
<div><br></div><div>---------------------------------------------------------</div><div>Bug #1221304</div><div><br></div><div>"Global app-menu is missing from panel..."</div>
<div><br></div><div><b>Reported by:</b> AG Restringere on 2013-09-05 /* who reported the bug? */<br></div><div><b><br></b></div><div>Affects: (the package information below)<br></div><div><b>Assigned to:</b> (Developers, Packagers, etc...to fix...) /* which developer or packager is fixing the bug? */</div>
<div><br></div><div><b>Managed by:</b> Stephen M. Webb, Alberto Salvia Novella /* who is triaging the bug right now? */<br></div>
<div><br></div><div>---------------------------------------------------------</div><div><br></div><div>The addition of this field would in no way alter current Bug Triage processes or methods that are currently in place, those would remain the same. This would just make it simple and clear what is going on with the bug without having to analyze comments. Then members could use the Launchpad search filters to find bugs don't have anyone managing them removing unnecessary complexity from the bug search process. This tool would simply be for informational purposes and everyone would still have access to the bug and be able to help triage it if they wanted to. </div>
<div><br></div><div>Best regards,</div><div>AG </div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Nov 5, 2013 at 6:45 AM, Alberto Salvia Novella <span dir="ltr"><<a href="mailto:es20490446e@gmail.com" target="_blank">es20490446e@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
I have to (constructively) disagree with these suggestions:<br>
<br>
- With the first one because, although it's an improvement, it's
just a <b>distraction</b> of what is really important now.<br>
- With the second one because of putting <b>barriers</b> in front
of collaboration, one key of success.<br>
- With the point of view in general because forgetting <b>simplicity</b>,
the ultimate goal of any system.<br>
<br>
<div><br>
El 04/11/13 23:32, AG Restringere escribió:<br>
</div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">
<div>
<blockquote class="gmail_quote" style="font-family:arial,sans-serif;font-size:13px;margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Bug
Squad does not have (i.e. to set the "Triaged" state and the
bug<br>
importance, as well as other bug-control specific tasks),
the<br>
"Assigned To" field on bugs is used to identify who the work
on fixing<br>
the bug is assigned to, not the triager.</blockquote>
<div style="font-family:arial,sans-serif;font-size:13px"><br>
</div>
<div style="font-family:arial,sans-serif;font-size:13px">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.</div>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">Assigning
one "triage owner" for a bug defeats the general idea of</span><br style="font-family:arial,sans-serif;font-size:13px">
<span style="font-family:arial,sans-serif;font-size:13px">that
collaboration of which myself and others are so fond of.</span><br>
</blockquote>
<span style="font-family:arial,sans-serif;font-size:13px">
<div><br>
</div>
<div>
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.</div>
</span><span style="font-family:arial,sans-serif;font-size:13px">
<div><br>
</div>
</span>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-family:arial,sans-serif;font-size:13px">I'm
confused here...(...)...</span><span style="font-family:arial,sans-serif;font-size:13px">In
comparison with the<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">packages'
bugs which I am specifically subscribed to, I've seen very<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">few
bug-control subscribed bug stuff, so I'm a little confused
with<br>
</span><span style="font-family:arial,sans-serif;font-size:13px">this
modification or concern.</span></blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.<br>
<br>
</div>
<div>Best regards,</div>
<div>AG</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Mon, Nov 4, 2013 at 4:15 PM, Thomas
Ward <span dir="ltr"><<a href="mailto:teward@ubuntu.com" target="_blank">teward@ubuntu.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey, AG,
thanks for splitting this off into a separate discussion.<br>
<div>
<div><br>
On Mon, Nov 4, 2013 at 3:54 PM, AG Restringere <<a href="mailto:ag.restringere@gmail.com" target="_blank">ag.restringere@gmail.com</a>>
wrote:<br>
> Re-posting my message to this list to create a new
thread about Bug Triage<br>
> procedures. I've outlined some ideas that I think
would really improve the<br>
> efficiency and clarity of Bug Triage operations.<br>
><br>
> --------------------------------<br>
><br>
> In my experience in - when I dabbled in some bug
control work as part of the<br>
> Ubuntu-X team - the Bug Triage process is still
very tedious and lacks<br>
> sufficient automation. Most of the time and effort
I spent doing bug control<br>
> work was spent browsing Launchpad and reading
through hundreds of bug-emails<br>
> in order to find bugs to work on. Most of my time
was spent searching for<br>
> bugs but very little of my time was spent actively
working on bugs and being<br>
> productive. Also, many times I saw bugs that had
comments from Bug Control<br>
> members but it was never clear who was working on
the bug or what they<br>
> wanted to do with it. This often lead me to add
comments when they weren't<br>
> needed or not contribute when a bug actually needed
attention and action.<br>
><br>
> Modifications I would make to the Bug Triage
process:<br>
><br>
> 1. Assignment and eliminating redundancy:<br>
><br>
> When a Bug Triager begins working on a bug they
should assign themselves to<br>
> the bug on Launchpad if they intend to actively
work on it. Only one Bug<br>
> Triage member should be assigned and actively
working on a bug at any given<br>
> time and they should effectively "own" that bug and
be responsible for it.<br>
> The only other people who should be working on that
specific bug should be<br>
> Reporters, Testers and Developers. Assignment
would help other Bug Triage<br>
> people to know "this bug is actively owned by
another member" and know to<br>
> move on to other bugs and leave that one alone. It
would be even better if<br>
> Launchpad could filter out the bugs that were
actively assigned to Bug<br>
> Control members so people could find those that
nobody was working on and<br>
> needed attention. Sufficient criteria for finding
new bugs could be as<br>
> simple as "Confirmed"+"Unassigned".<br>
<br>
</div>
</div>
I am against this suggestion as it stands, maybe because I
do not<br>
understand your reasoning for it or the potential execution
of this,<br>
but also because there needs to be made a distinction, in my
opinion,<br>
between the role of Bug Triager and the role of "Package
Fixer" (for<br>
lack of a better term, this would be someone with the
package<br>
knowledge and development knowledge to fix the bugs once
they're<br>
"Triaged").<br>
<br>
A triager may help get the bug from New to Triaged or New to<br>
Confirmed, but ultimately someone with developer knowledge
of the<br>
package, or the knowledge to patch the package, is going to
be the one<br>
the bug is "assigned" to for the work item. As well, a
single<br>
individiual triager may have to collaborate with other
triagers in<br>
order to get the package to the "Triaged" state. I myself
have<br>
collaborated with other bug controllers and bug triagers in
order to<br>
get bugs moved along to a point where a developer can work
on the<br>
bugs, and in most cases, I quite like that collaboration.
That<br>
collaboration would then, in a sense, mean that all the
triagers who<br>
have collaborated on it are "owners" of the bug for a
triaging sense.<br>
Assigning one "triage owner" for a bug defeats the general
idea of<br>
that collaboration of which myself and others are so fond
of.<br>
<br>
Also, unless you're proposing changing the bug system to
have an<br>
additional "Triage Owner" role and field on the bug and
restricting<br>
"Triage Owner" to bug controllers who actually have the
access that<br>
Bug Squad does not have (i.e. to set the "Triaged" state and
the bug<br>
importance, as well as other bug-control specific tasks),
the<br>
"Assigned To" field on bugs is used to identify who the work
on fixing<br>
the bug is assigned to, not the triager. I still stand by
this,<br>
because as one of the people primarily working on the nginx
package<br>
now, I have seen people assign themselves to bugs and fix
them, or<br>
assign themselves, and then hand me the work later, and
reassigning it<br>
to me as the person who will fix it or SRU it or whatever.<br>
<div><br>
><br>
> 2. Email volume reduction:<br>
><br>
> Bug Triage members should only receive emails about
bugs they're actively<br>
> assigned to. It's really time consuming to sort
through hundreds of<br>
> bug-mails that involve bugs that are not relevant to
ones currently being<br>
> worked on. This applies to all roles such as
Testers, Reporters and others<br>
> as well. The only general emails that should be
received should be from the<br>
> discussion or developer mailing lists.<br>
<br>
</div>
I'm confused here. As a Bug Squad member, I have received
exactly 0<br>
email addresses for subscribed bugs, in that the Bug Squad
isn't<br>
subscribed to any bugs by default. As a Bug Control member,
I see<br>
some crash bug data for which bugcontrol is subscribed to,
or is a<br>
member of one of the teams subscribed. In comparison with
the<br>
packages' bugs which I am specifically subscribed to, I've
seen very<br>
few bug-control subscribed bug stuff, so I'm a little
confused with<br>
this modification or concern.<br>
<div>
<div><br>
><br>
> 3. Auto-assignment process queue:<br>
><br>
> Similar to a tech-support ticket system the next
step in this process would<br>
> be to introduce a process queue with
auto-assignment of bugs to Bug Triage<br>
> members. I don't know how this would work but some
status change in the bug<br>
> would have to trigger it's submission it into the
process queue such as<br>
> reaching a Confirmed status or increased Reporter
activity at some threshold<br>
> level. The distribution of the bugs would have to
take into account the<br>
> work-load of the Bug Triage members and distribute
them evenly but perhaps<br>
> that's a bit too complicated to do in code. Maybe
random assignment would be<br>
> better or it could based on the package selection
preferences of individual<br>
> members. Perhaps there could even be some senior
Bug Control members who<br>
> would manually assign the bugs from the queue.
This would eliminate the<br>
> need for Bug Triage members to even need to go to
Launchpad to search for<br>
> bugs unless they're doing some extra research.
Bugs would be sent to them<br>
> via email automatically when they're ready to be
triaged and auto-assigned<br>
> without any extra steps needed.<br>
><br>
> Conclusion:<br>
><br>
> If the above steps were implemented or some
equivalent processes I think the<br>
> Bug Triage would be streamlined, eliminate
redundancy and get faster<br>
> turn-around times. Bug Triage members would be more
focused and successful.<br>
> Newer Bug Triage members would be able to be
"plugged in" to a standardized<br>
> process and this would improve retention because
people would see results<br>
> faster with less effort.<br>
><br>
> --------------------------------<br>
><br>
> Hopefully the feedback and ideas above can be
tested in some form and<br>
> implemented.<br>
><br>
> Best regards,<br>
> AG<br>
><br>
</div>
</div>
> --<br>
> Ubuntu-bugsquad mailing list<br>
> <a href="mailto:Ubuntu-bugsquad@lists.ubuntu.com" target="_blank">Ubuntu-bugsquad@lists.ubuntu.com</a><br>
> <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad</a><br>
><br>
<br>
------<br>
Thomas<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset></fieldset>
<br>
</blockquote>
<br>
</div></div></div>
<br>--<br>
Ubuntu-bugsquad mailing list<br>
<a href="mailto:Ubuntu-bugsquad@lists.ubuntu.com">Ubuntu-bugsquad@lists.ubuntu.com</a><br>
<a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad</a><br>
<br></blockquote></div><br></div>