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