Reporting Ubuntu Community Problems

Recently I have been thinking a lot about how we can refine and improve how we report problems and issues in the Ubuntu community. I shared some thoughts about this a little while back and I have been talking with many people inside the Ubuntu community, at the Community Leadership Summit, and with our Community Council and Technical Board about how to flesh out a better, more effective, and more visible process. Today I want to share the fruits of these efforts.

Before we continue I want to be clear: this is a work in progress. This is not final, it is not decided and it is not perfect. The process I am about to illustrate is a first shot that we can put into place, and at UDS I am going to schedule some sessions in which we can review and improve on the process.

The idea is simple: we want to have a place in which our community can report a problem with a community processes or infrastructure and ensure the relevant group or governance body can be assigned to tend to the issue, discuss it as part of their regular meetings and otherwise have it on their radar. The way this will work is that problems are reported as bugs in the ubuntu-community project and preferably assigned directly to the right group, otherwise, other people can assign the bug to the right group. What is important here is that we clearly define what kind of problems should be assigned where.

We will then work with our governance bodies to ensure that as part of their work they review these bugs and help to resolve them. I would like to encourage our governance bodies to build these bugs into their work.

The process looks like this:

Step 1: Chose the right place to report the problem

We first need to ensure the right team in the Ubuntu project know about your problem:

• If your problem relates to general community governance or the Community Council then note down communitycouncil
• If your problem relates to technical policies or the Technical Board then note down techboard
• For all other issues you don‚Äôt need to note anything down.

Make a note of the team name, we will use in just a moment.

Step 2: Report the problem

You can now provide us with some details of the problem. This involves three simple steps:

1. Middle click (or press both mouse buttons together) on this link.
2. You will be first asked for a Summary. Here type in a short and descriptive single-line summary of the problem.
3. You are next asked if your problem already exists in the system and a list of possible existing problems will be shown. You can click the arrows to show more details about each problem.
   • If one of the problems describes your problem, click the Yes this is the bug I‚Äôm trying to report button.
   • If the problem you are reporting is not in the system click the No, I need to report a new bug button.
4. On next page do the following:
   • Type in some details about the problem in the Further Information box. Try to be as detailed in your description as possible.
   • Click the Extra Options link and in the Assign to box write in the team name you wrote down above. If you didn‚Äôt write down a team, or you don‚Äôt know it, don‚Äôt worry, just leave this box blank.
   • Finally click the Submit bug report button.

When your problem has been filed, you will receive an email with a link to the problem in Launchpad, and you can view that link to see the latest details about the problem.

I have documented this process here and also created two other documents which will help us improve it:

• Best Practice – much of what I am hoping we can achieve is building best practice around how we handle reported community problems. As an example, in some cases we will want to develop a spec or solution out of problems to help move it forward. Note down areas of best practice on this page.
• Feedback – opinions and ideas on the process and what does and does not work can be added on this page.

As I said earlier, I am keen that we review this process at UDS and see how well it works.