ubuntu-bugcontrol team mailing list archive

[Daniel Manrique <daniel.manrique@xxxxxxxxxxxxx>]

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)