ubuntu-bugcontrol team mailing list archive

["Emmet Hikory" <persia@xxxxxxxxxx>]

Brian Murray wrote:
> This application to the Bug Control was e-mailed to me directly so I am
> forwarding it for the team's consideration.

    I don't usually respond to these, and am unsure if my comments
carry any weight in the context of a bug control application, but feel
that this specific application is not sufficiently strong, and
encourage the Bug Control administrators to request further examples
of work prior to accepting the application.  Specific reasoning
follows:

Devid Filoni wrote:
>> 5) I also need to see a list of five or more bugs which you have
>> triaged.  These bugs should demonstrate your understanding of the triage
>> process and how to properly handle bugs.  If there is a bug in your list
>> that does not have an importance indicate what importance you would give
>> it after becoming a member of Ubuntu Bug Control.  Please use urls in
>> your list of bugs so I can more easily find them.
> https://bugs.launchpad.net/ubuntu/+source/varkon/+bug/246729 the importance of this should be wishlist
> https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/251926 the importance of this should be medium
> https://bugs.edge.launchpad.net/ubuntu/+source/libgphoto2/+bug/252408 the importance of this should be wishlist

    These three are all self-reported bugs, and seem to violate the
guideline about triaging one's own bugs.  While sometimes one has
sufficient information to be certain of the bug, and that it contains
sufficient information to meet triage guidelines, it is *always* best
to ask for a second pair of eyes to ensure that the bug is indeed
completely triaged, and that one hasn't forgotten something.

> https://bugs.launchpad.net/ubuntu/+source/gnome-python-desktop/+bug/220301 in this I changed the affected package

    I don't feel this bug received much triage: while the package name
was corrected, it would certainly be interesting to know why that
package was selected, and maybe some information on the nature of the
bug in gnome-python-desktop.  Some of this could be determined by
package investigation, and some perhaps by discussion with the
submitter.  I'd be more likely to overlook this non-triage if the bug
had been self-assigned for fix, and there was evidence of work with
the larger development team to upload, as perhaps it's not so
important to fill in all the details when one is fixing it, but in the
absence of that I'd like to see more text.

> https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9/+bug/252793 in this I changes the affected package

    Whlie the affected package was corrected, I'm not sure that the
bug was triaged as such: it seems more a minor correction performed
whilst someone else has declared they were working on a solution.  It
is precisely this sort of adjustment that led to previous discussions
about "workflow bugs" and whether they should be triaged.  While this
certainly isn't a "workflow bug", it ought be safe to expect that if
someone has committed to working on a solution, they would be best
placed to set the package, and to perhaps communicate with them before
making adjustments.  In the hopes of reducing any possibility of such
fuss in the future, I'd like this sort of minor adjustment without
deeper triage to be discouraged in cases where someone has committed
to fixing the bug, and hence not be used in support of an application.

    Note that I am familiar with Devid's work with the development
team, and believe it to be of high quality.  He has shown a
willingness to tackle what others consider impossible problems, and a
facility for coordination with several upstream groups (including
cases where we have multiple upstreams that disagree on outstanding
issues).  I just don't feel that the bugs outlined above demonstrate
sufficient facility with the triage process to warrant membership in
the Bug Control team.  That said, were this a selection of bugs
reported by users, and fixed by Devid without long commentary, I'd
feel that was an example of effective triage, although perhaps weakly
documented, as it would demonstrate the ability to understand the
problem from the bug description, and ensure there is sufficient
information for a developer (Devid in this example) to prepare a
solution (which I believe to be the primary goal of bug triage).

-- 
Emmet HIKORY