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 _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
