On 06/30/2011 08:25 AM, 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. > > Kindest regards, > > - Daniel Manrique (roadmr) >
Hi Daniel, With the exception that Robert already mentioned, I think this is all excellent. Your linked reports show a broad understanding of the triage process. I approve. David _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-bugcontrol Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-bugcontrol More help : https://help.launchpad.net/ListHelp
