ubuntu-bugcontrol team mailing list archive

[Daniel Manrique <daniel.manrique@xxxxxxxxxxxxx>]

On 11-07-06 02:39 PM, Brian Murray wrote:
> On Thu, Jun 30, 2011 at 08:25:38AM -0400, Daniel Manrique wrote:
>> Hello,
>>
>> I'm writing today to request joining the Bug Control team. I believe I
>> could be more helpful in the triaging process as part of Bug Control,
>> both to be able to better handle bugs I'm triaging and to assist other
>> triagers in reviewing and setting the desired bug parameters.
>>
>> I've only been triaging bugs for a few months now, but I've tried to
>> touch a wide range of bug reports to get a better feel of the process,
>> as well as as much experience as possible, so as to avoid pestering
>> other triagers and members of Bug Control. Their guidance in
>> #ubuntu-bugs has been invaluable in my getting acquainted with the
>> process and more confident in triaging bugs by myself.
>>
>> Please note that, as I work within Canonical's Hardware Certification
>> team, I already have some bug handling privileges, but this is subject
>> to the usual conditions for team access to Bug Control, which I've been
>> careful to respect.
>>
>> As per the application process, here are my answers to the application
>> questionnaire.
>>
>> 1. Do you promise to be polite to bug reporters even if they are rude to
>> you or Ubuntu? Have you signed the Ubuntu Code of Conduct?
>>
>> I have signed the code of conduct
>> (https://launchpad.net/~roadmr/+codesofconduct) and promise to be polite
>> to bug reporters even if they act rudely.
>>
>>
>> 2. Have you read Bugs/HowToTriage, Bugs/Assignment, Bugs/Status and
>> Bugs/Importance? Do you have any questions about that documentation?
>>
>> I have read all four documents and still rely in them to avoid making
>> mistakes while triaging. I have no questions, other than a comment, it
>> being that while most info is available and documented in the wiki
>> pages, sometimes it's scattered around and it can be a bit hard to have
>> an overview of everything that's needed to work on triaging, I think
>> something like the "ultimate triager's handbook" could eventually be
>> helpful to reduce the amount of cross-linking between documentation, for
>> people who want to read a top-to-bottom document to get acquainted with
>> the process.
>>
>> 3. What sensitive data should you look for in a private Apport crash
>> report bug before making it public? See Bugs/HowToTriage for more
>> information.
>>
>> Mainly:
>> - A core dump file, if it exists, has to be removed (CoreDump.gz).
>> - Stack trace attachments, which are text files produced by the
>> retracing service from the core dump, need to be scanned for potentially
>> sensitive information such as passwords and banking information.
>> - I ran into a case where ubiquity --debug puts passwords in the debug
>> log, and now know to also check ubiquity logs for this information. This
>> is not automatic though, the user has to specifically enable debugging
>> for this to happen, so it's not as common as the core dump and trace files.
>>
>> 4. Is there a particular package or group of packages that you are
>> interested in helping out with?
>>
>> I tend to focus on the packages I know and use the most, such as
>> Ubiquity, the Checkbox system testing tool, and the Linux kernel, mainly
>> because some knowledge of the software I'm triaging is always useful.
>> But I'll help anywhere I can.
>>
>> 5. Please list five or more bug reports which you have triaged and
>> include an explanation of your decisions. Please note that these bugs
>> should be representative of your very best work and they should
>> demonstrate your understanding of the triage process and how to properly
>> handle bugs. For all the bugs in the list, please indicate what
>> importance you would give it and explain the reasoning. Please use urls
>> in your list of bugs.
>>
>>
>> Here they are:
>>
>> - Kernel panic only when rebooting -
>> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/784484. Importance
>> was set to Medium as it's easily workaroundable but it is a problem with
>> the Linux kernel and looks like a regression too, so I didn't think it
>> was good to set as Low. Charlie Kravetz set the importance and status
>> for me, but I made the decision (really!).
>>
>> - Update Manager truncates text -
>> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/787779 .
>> Set to medium per "moderate impact in a core application" and "usability
>> issue that does not limit functionality". Can't be low because it's a
>> core app and it affects potentially all non-english speakers.
>>
>> - Feature request for a cryptic operator in gcalctool:
>> https://bugs.launchpad.net/gcalctool/+bug/793831. Set as triaged with
>> importance: wishlist as it is a feature request. I also filed an
>> upstream bug request in behalf of the bug reporter, requesting the feature.
>>
>> - Unity dock conflicts and misbehaviors.
>> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/780962. Triaged as
>> a duplicate and moved to the correct package (Unity) as it was initially
>> assigned to libreoffice. The primary bug is importance: high (impacts
>> accessibility a core application and has moderate impact on large
>> portion of users).
>>
>> - A checkbox bug asking for keyboard usability.
>> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/724540. We
>> suggested a workaround for the user. Marked fix released as per "for a
>> problem fixed in the latest development release" and importance low as
>> per "has an easy workaround".
>>
>> - Checkbox upgrade failed.
>> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/753243. I
>> initially set this as a duplicate of another bug, upon closer analysis
>> (with help from jibel) it turned out they were different problems,
>> though both are invalid, so I de-duped them and set this one as invalid
>> since it was using non-ubuntu packages. As it is invalid I set no
>> importance; I hesitate to speculate on the importance it would have had,
>> if it had been a legitimate problem, could have been anywhere from low
>> (easy workaround) to high (had it been a general problem in a Python
>> library).
>>
>> - Checkbox feature request that already existed:
>> https://bugs.launchpad.net/ubuntu/+source/checkbox/+bug/786968. I marked
>> this as invalid (user error). Importance would have been Wishlist if it
>> hadn't already been implemented.
>>
>> - Uninstallable non-Ubuntu application, due to bad Python programming.
>> https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/788771. Set as
>> invalid as it is not an Ubuntu-supplied package, if it had been an
>> Ubuntu package I would have set importance to medium as "has a severe
>> impact in a non-core application" (basically uninstallable). I asked the
>> reporter to request help from the application developers, and also
>> linked to an upstream bug report indicating that the behavior has been
>> fixed in new version of Python. Finally, the analysis I did of the
>> behavior might enable the app developers to fix their code so as to
>> prevent possible, future bug reports about the same problem.
>>
>>
>> Thanks for taking my application into consideration, I hope to be able
>> to continue doing useful work with Ubuntu bugs, regardless of your
>> decision on this request.
> 
> Based on the positive feedback for your application to the team I am
> happy to approve your membership in Ubuntu Bug Control.  Thanks for
> helping out and welcome to the team!

Awesome, thanks! now, off to triage some bugs...

> --
> Brian Murray