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