To the Ubuntu Bug Control Team,
Please see my following application for membership in the Ubuntu Bug
Control team.
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?
Yes, I promise to always be polite and professional when interacting
online on behalf of Ubuntu. I understand that encountering software
bugs can be frustrating for users and some can feel quite passionately
about it. It is important to empathize with the user and make them
feel heard, while gathering necessary information to address the
issue. I have signed the Ubuntu Code of Conduct as part of my
onboarding process with Canonical.
2. Have you read Bug triage, Bug status, and Bug importance? Do you
have any questions about that documentation?
Yes, I have read those documents and have put them into practice when
triaging and addressing snap-openstack (Sunbeam) bugs for the Ubuntu
OpenStack team. I have no questions about the contents.
3. What sensitive data should you look for in a private Apport crash
report bug before making it public?
Apport crash reports should have the CoreDump.gz files removed since
they could contain sensitive data about a user's system. If the stack
trace is good enough, the CoreDump.gz should be removed from the
report (mark 'invalid,' if not). A bug report containing CoreDump.gz
should never be made public. In general, the bug report should be
looked over for any sensitive or identifying information such as
passwords, user names, server names, IP addresses, API keys, banking
information, etc.
4. Is there a particular package or group of packages that you are
interested in helping with?
I am currently on the OpenStack bug triage team and would like to have
my privileges expanded for all Ubuntu packages to assist with my work
with the MIR team. MIR reports are written as bugs and when an MIR is
identified as requiring a security review, the Ubuntu Security team
needs to be assigned. My current privilege does not allow me to assign
bugs outside of my own team.
5. List five or more bug reports you have triaged, and include an
explanation of your decisions. These bugs should represent your very
best work and they should demonstrate your understanding of the triage
process and how to properly handle bugs. For each bug in the list,
indicate what importance you would give it and explain the reasoning.
Provide URLs in your list of bugs.
1. https://bugs.launchpad.net/snap-openstack/+bug/2122469 - This bug
is related to the '^C' command causing issues with the terminal
when used on a Sunbeam process. I triaged this bug as a 'medium'
as while it presents a usability glitch when a process is
terminated prematurely, a workaround was presented by the bug
reporter. This is the type of issue that should be fixed in the
medium term but does not present an issue with deployment or setup
of Sunbeam which would take precedence.
2. https://bugs.launchpad.net/snap-openstack/+bug/2114956 - This bug
is related to a Tempest test failure when running the standard
smoke test for Sunbeam in the CI environment. This was triaged as
a 'medium' priority bug as this bug was intermittent, likely
exposing an occasionally-occurring race condition within Sunbeam
when run on the QA CI environment. This issue cannot be reproduced
locally so it is not presenting an issue to end users but should
be fixed in the medium term as any failures that present in QA
could be masking other problems with the product.
3. https://bugs.launchpad.net/snap-openstack/+bug/2106130 - This bug
relates to incorrect documentation links within Sunbeam. This was
also triaged as a medium (and promptly fixed by myself as I was
already working on that part of the codebase) because the links in
question were to the old documentation set which was still up and
valid, but we wanted to move all internal references to the new
Sunbeam documentation set at a different domain. This bug did not
present an immediate usability or quality-of-life issue to a user
but should have been fixed relatively quickly as the old
documentation set was being taken offline within a couple months
of the report.
4. https://bugs.launchpad.net/snap-openstack/+bug/2110524 - This bug
relates to a user request for the 'manifest' file of Sunbeam to be
routable to 'stdout' rather than only to a file. This was triaged
as a 'wishlist' item because Sunbeam was designed to only create a
manifest.yaml file and not direct the manifest to stdout. This is
not a problem with the way the product was intended to work,
however, that is a reasonable feature request and something that
could be added in future work.
5. https://bugs.launchpad.net/snap-openstack/+bug/2101130 - This bug
is related to the Tempest output not being created at all when a
test fails. This was triaged as 'high' because this presents a
significant blind spot in our QA CI environment and makes it
extremely difficult to know what triggered a failure when one
occurs. This is a higher priority than a bug labelled 'medium'
because it presents an issue when any CI failure occurs, not just
a specific failure, but it is not critical as it does not present
a blocking issue for an end-user of Sunbeam in production. It is
the type of issue that should be fixed within a week.
Thank you for your consideration. Please let me know if you need any
further supporting documentation.
Kindly,
Myles Penner (~mylesjp)
