This page is meant to be a virtual whiteboard for members of the QATeam when brainstorming new ideas for the QA efforts of Ubuntu.

If you have any ideas, please feel free to discuss them on the [https://lists.ubuntu.com/mailman/listinfo/ubuntu-qa mailing list] and the irc channel (#ubuntu-quality on Freenode).

Idea Pool

Ideas on this page are to be considered a 'work in progress' and not as official statements by the QATeam or any group member. Please feel free to add ideas below and make comments.

Better Bugfixing Documentation

The current bug process has a hole in the documentation:

1. Find / Report Bug
2. Reproduce and triage the bug
3. ?????
4. Upload patch!

We need to find, aggregate, write or otherwise document common strategies for fixing bugs. Things like VCS bisection, using GDB to find the cause of a segfault, installing debugging symbols and so on. Language specific stuff could also help, but at least getting a few strategies documented somewhere we can point people to would help them help themselves, and the larger open source community. Crimsun suggested OpenSolaris has documents on the subject; we might want to Liberate them for the Greater Good.

Dev / Triager Training Days

The purpose of one of these days (which could be rolled with an UbuntuBugDay) is to provide a space and time for developers to ask bug triagers questions on best practices.

The rationale for this is that many developers started doing their work before many new changes in the way triage happens in Ubuntu and Launchpad came about. What makes this different from a general "learn how to triage" event is that it is focused on helping developers, not triagers (specifically, but triagers are welcome to attend).

Some things to cover include:

• Providing a list of "need-to-have" information for debugging a particular package (logs, traces, etc).
• Communicating the severity of a bug via the Importance field in LP.
• ...