This plan is available for download in PDF format.

Making QA Simpler For Community

One thing I have found is that the work itself cannot be made 'simple'. However, there are things we can do to make it look and feel simpler to someone coming into QA. The process as it stands now is very confusing and it takes too much time to align things to work, which ends up frustrating people trying to find a path.

Listed below are some items based off of talking with people who are currently involved within the Ubuntu QA Team and things I have found by looking at the system that can be improved upon to help streamline the system and honestly, make it better for people looking to help.

The implementation of these items will require a team from the current QA Team personnel to accomplish, however, when organized properly, will not require much time to do. During my conversations with members of the QA Team, it came up that the QA people are actively looking for ways to include the Community in more ways. From these conversations, I know I will have instant help in simplifying (and in the process of simplifying the system it will have a byproduct of refining it as well) the system.

• Build a system of clear parts of the QA system. A series of information located in one place that explains the different parts of QA and the work involved.

• Create a series of Todo lists laying out what needs to be finished (see https://www.kubuntu.org/Kubuntu/Todo )and give a time-line for it. As it stands this seems to be done internally. These things need to be displayed to encourage community help.

• Establishing a better documentation system on how to get involved. Using the QA professionals within Ubuntu QA to build a flow chart to place people where they can be used to their full potential.
• Making the process of Testing QA and Bug Squad/Control and how to get involved in a central location.
• Reset the face in all areas of QA to be more user-friendly including how non-devs can get involved. Writing instructions that will appeal and is readable to non-devs.

Improve and Refine Ubuntu QA

The biggest issue I have found thus far is there is no clear path through the QA area of Ubuntu. There are a few snippets here and there if you really go digging. There is plenty of programs in place that the community can help, but it is not an apparent, clear path forward.

Most of the list below has to do with presenting a better layout and face on what we expect from QA as well as how to do each little thing within the world of QA. QA can be a lot of fun if you know how and why you are doing what you are doing.

Problems and solutions

Listed here are a few problems and solutions to the individual problems:

Problem The feeling from someone outside trying to find out information is that the teams are a bit spread out.

Solution Building and publishing better goal sets within the release cycle on what needs to be done when. Placing it in an easy to find area so that it can be viewed and reviewed.

Problem: No clear direction for people to follow on how and when things need to be done.

Solution: Build a defined, clear goal set of what needs to be done and a todo of when it needs to be accomplished. (See Kubuntu/Todo) + a time line/deadline

Problem: Not understanding the work and time involved for the teams and projects.

Solution: Taking the testing team and making it clearer what each function does and having a clear explanation of the work, so that people understand what it will take to accomplish a goal set.

Problem: No clear understanding of what level of quality or what is expected from the testing / work.

Solution: Build a requirement/expectations document for the processes so that people coming in will understand and know what is expected of the work.

Problem: Lack of people knowing what needs to be done within the QA community.

Solution: Communication with the Locos about QA. Hold some training and lots of emails to help people understand the ways they can help even if they are not developers. Sending emails, publishing with the locos and with other 'news' sources. UWN, Fridge, planet etc. Using the ideas of a "Global Jam" for QA days.

Problem: A lack of understanding where the community can assist and do QA work.

Solution: Finding (by talking to the QA people) what the community can/should handle to allow them to work within the requirements that Canonical has set up.

Problem: Getting lost in the lingo and wanting to close my browser out of frustration.

Solution: Building the 'face' of QA so it looks less like techno-babble and really allow people to have an understanding of what goes on and what it takes to get things accomplished.

Problem: Not understanding what exactly it is that bug triage and developers are looking for in bug reports.

Solution: Centralizing the Bug Squad / Bug Control documentation so that people can easily find what they are looking for. Example: The status and how to come to those conclusions. The documentation is there, it's just hard to find.

Problem: Developers are frustrated about the lack of communication between Bug Squad and Devs.

Solution: Building a better connection between finding/triaging bugs and fixing them. Have the triagers and the devs work together to spot and fix bugs before a release.

Problem: Finding a place for non-dev and devs willing to help in QA.

Solution: Better publishing QA and Testing for dev and non-dev work within the contribute sections, so that people can find them better and know what they can handle.

Problem: QA Professionals and others being turned to Bugs when asking what they can do to help.

Solution: Having a better guide to give people asking about QA work than just bug squad. Having a document that takes experience and places it within the scope of a team/teams.

Problem: The look and feel of QA within Ubuntu feels disconnected and hard to figure out.

Solution: With a better 'snapshot' overview look at the different bug and testing teams, it will make the QA process look simpler without actually slacking on the quality of it.

Problem: No clear accountability for the teams.

Solution: Build a level of governance within the QA team and Bug Teams. This way there is clear leadership and accountability level. This way there can be a direction center.

Wish List

• A way to track trends.
• Getting with QA to build better hooks for Apport.
• Better explanations on the Bug system and how it is supposed to work.
• Clear Documentation for Bug Teams and QA Teams.
• Have lists of things todo for QA and bugs for the devs and non-devs of the community who come in to help.
• Implementing a governing program via a council to help work issues and ensure that all teams are on the same page. The council will also hold accountability within the teams, set directions, time-lines etc.

A Path Forward

Taking everything I have learned and what I have yet to learn with ideas Pete Graner has along with other members of the community, I have a good understanding of where to start. Because of how the process is currently set up, it would be as confusing for anyone else as it was for me to start flooding the system.

The first couple of weeks would need to be spent preparing QA for an influx of Community. This would take myself, Pete Graner and leaders within Ubuntu Community getting together for a series of meetings to put a "Community Friendly" face on QA. This will include, but not be limited to the following:

• Gather a list of teams within the QA and Bug teams so that we know what work is being done by whom.
• Get the information that is spread within the teams on how to get involved and build a complete "getting involved" page.
• Prepare the current members on what to expect when people come looking to learn and contribute, how to deal with the influx of training.

Once these pieces are in place, we can start pushing people toward the system.

Buzz

• Holding a series of "QA Week" programs. They will include training and focused parts of QA, depending on when they are in the cycle. Announce these via Loco Teams, OMG Ubuntu and other Ubuntu news outlets.
• Holding "QA Training Days" to help people learn about QA and how to accomplish goals.
• Use "Bug Day" to its maximum potential. Include areas and direction for developers to fix the problems and mark this with members of MOTU to get the issues found and fixes updated.
• Blog, news, blog, news.

From here it will be a bit of reaction and finding ways to solve the issues noted above as well as fixing new issues that will crop up.

Action Items

June 2011

Coordinate with QA Manager

People Involved: David Wonderly and Pete Graner

Time frame: June 15-20

Actions:

• Find his ideas, plans for QA and Community Interaction.
• Talk to him about the issues I have found and how we can work together to make QA more Community-friendly.

Build a Community Friendly Face to QA

People Involved: David Wonderly, QA Team

Time Frame: June 15-30 (After meeting with Pete Graner)

Actions:

• Hold meeting with QA Team.
• Find information on QA time lines, work load and due dates.
• Build a document with QA Team to list the needs and requirements of QA to share with Community.
• Discuss where would be a good place for Community members to start contributing.

Create a Community QA Launchpad Team

People Involved: David Wonderly, Current Community QA People

Time Frame: Early June 2011

Actions:

• Create LP Team.
• Come up with documentation on how it will be used.
• Configure Blueprints for actions.

Refine Bug Triage, Devel and Packaging Interactions

People Involved: David Wonderly, Bug Squad, Bug Control, Developers, MOTU members.

Time Frame: June 15-30

Actions:

• Collaborate with the four teams listed to find a process to make things smoother during transitions.
• Find what the Developers expect from bug reports.
• Document a process for further interactions and get it implemented within the bug training process.

Refine the Bug Mentoring Program

People Involved: David Wonderly, Bug Squad, Bug Control

Time Frame: June 15-30 (After the meeting with MOTU, Devel and Bug Teams)

Actions:

• Discuss the pros and cons of the current mentoring program.
• Build a stronger, better system for training and mentoring people using information gathered from developers and Packaging.
• Document the new process and document the changes so people can understand the system better.
• Implement the new mentoring program.

Build a Community Leadership Team in QA/Bug Teams

People Involved: David Wonderly, Community Members involved with the current system.

Time Frame: End of June

Actions:

• Prepare the current Community members for a stream of new members.
• Talk to the current "senior" Community QA members about how to become Community Leaders and lead their teams.
• Build a series of documents to help with accountability issues.

July 2011

Gather Buzz About QA

People Involved: David Wonderly, Community, News

Time Frame: Beginning July and ongoing.

Actions:

• NOTE: Make sure all action items stste where you can get the information for both Devs and Non Devs.

• Get word out via Locos working with the Loco Council.
• Announce with Blogs on the planet.
• Ubuntu News (UWN ect.).
• Ubuntu News sources. (Ubuntu Magazine, OMG Ubuntu, etc).
• Other support teams.
• Blogging, Blogging, Blogging!

Create a Location Flowchart for Placing Volunteers

People Involved: David Wonderly, QA Teams

Time Frame: July 1-10

Actions:

• Build the flowchart so volunteers can see where the perfect fit will be based on what they know.
• Implement flowchart to the community.

July Into the Rest of the Oneiric Cycle

• Follow the time-line plans marking when milestones are met.
• Use Blueprints to track projects and accountability.
• Ensure we maintain Buzz, building from this Todo based on meetings and needs coming from QA and Bug teams and maintain Buzz.
• Taking the ideas of Bug Jams and Developer Week to build a QA Week system with training and concentrated work.
• Ensure Bug Jams and Global Jams have better processes of what we expect in the way of quality and quantity.