ubuntu-bugcontrol team mailing list archive

[Brian Murray <brian@xxxxxxxxxxxxx>]

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!

--
Brian Murray

Attachment: signature.asc
Description: Digital signature