Ubuntu Wiki

From The Art Of Community by O'Reilly (http://www.artofcommunityonline.org) by Jono Bacon

Introduction

Tools are a means to an end. They are used to produce something more interesting than the raw material and tools used to manipulate it. To select the right tools for the job, we need first to understand what we are trying to achieve. We need to know what our workflow is. We see differences in how we keep TODO lists, how we manage email, how we organise our important documents. Our methods of working and organisation styles vary. A successful workflow requires understanding what you want to achieve and making the steps in which you achieve it as simple as possible for as many people as possible.

Roles

The first task in understanding workflow: know your audience. People always have expectations. Our job is to understand, predict, and cater to fair expectations in our target audience. To understand these expectations, we need to understand our audience. Although communities are a breeding ground for diversity of personality, experience, and background, we can often see similarities in expectations, skills, experience, and approaches between people who have a shared interest in a particular type of work, be it programming, documentation, testing, advocacy, or whatever else.

• Roles are critical in identifying preconceptions and experience.
• Understanding the audience requires observing them in their natural environment.
• Your own experience will also guide how you build strong community and identify with these different roles.

Building a Simple Workflow

After establishing roles, we now need to sit down and flesh out a workflow. To do this we will identify an “OBJECTIVE,” the “AUDIENCE,” and then a number of “OUTCOME” steps that can achieve the objective. An example will best illustrate how that works.

Example: Jokosher user feedback, in order to improve the Application.

When I was involved in Jokosher, we wanted people to test the application and provide feedback. We wanted to take a snapshot of the application for members of our community to test and tell us when things went wrong. This would give us an opportunity to fix remaining bugs. That helps us produce the first item in our workflow specification, the objective that you want to achieve:

OBJECTIVE: To have more users install and test a development snapshot of Jokosher and provide feedback on bugs.

The next step is to identify the audience. We did not want developers to test Jokosher; we wanted real users to test it. We wanted people to use Jokosher for real music production and make assumptions based on real use cases.

THE RISKS OF AUTOPILOT A common problem that can occur when observing how people use software is when the user knows of a particular quirk in a product and works to naturally avoid triggering the quirk. This is common with software developers, and before release, the software typically is not used in the same manner as it is by normal users after release. A good antidote to this problem is to simply put new users in front of the software who are entirely unaware of the quirks and oddities. They can often present the most valuable feedback.

Let’s now add our audience to our spec:

AUDIENCE: Musicians or audiophiles who have basic computer knowledge.

The next step is in describing the primary pieces in the workflow. At this point we’re just identifying the major steps; we’ll add the details later. Add these as a series of OUTCOME items.

For example:

• OUTCOME: Install a current snapshot of Jokosher and all required dependencies.

• OUTCOME: Use and test primary features in Jokosher.

• OUTCOME: Provide feedback about bugs.

These three outcomes are the major steps involved in achieving our OBJECTIVE. The next step is to combine our AUDIENCE with each OUTCOME. This is the most important part of the process, where we assess how to make our workflow as simple and attuned to our audience as possible.

Let’s look at our first OUTCOME in the preceding list as an example. We need to combine this with our audience of new users. How can we make it as easy as possible to install Jokosher for a user base that is not technically sophisticated? When we were faced with this challenge, we considered a range of options. We heard some suggestions to provide simple documentation that would show people how to compile code and install dependencies. That was too technical and complex as an option. There were also suggestions to make packages available for each distribution. That required skills that were not present in the team, and would involve sourcing external help.

The ideal scenario was that someone could simply download a file and Jokosher would run: this matched our audience profile. It would be simple, easy, and efficient, perfect for our users. Stuart Langridge produced a script that downloaded the Jokosher code, installed the relevant dependencies on the user’s system, and ran Jokosher with a click of the mouse. The script checked to see whether the dependencies were already installed, and skipped their installation if they were. The user could use the same script for the first run and subsequent runs, and not even think about the concept of installation. Simple.

In the workflow spec, you should document each step from the perspective of your AUDIENCE. For the Jokosher installation example: OUTCOME: Install a current snapshot of Jokosher and all required dependencies.

• Download a script from jokosher.org.
• Make the script executable (explained with documentation).
• Double-click the icon to run the script and install Jokosher.
• To re-run, double-click the icon again.

This process was as simple as we could make it for the user. The hardest part was making the script executable, and there is no safe technical solution to automate that process. Our solution also required few resources to develop, just the time for one person to produce the script instead of lots of packagers to package Jokosher for every conceivable Linux distribution.

Once you have written your workflow steps into your functional spec, you should now go through each step and ask the following questions of it:

• Is this step really required?
• How easy is this step to understand? Could it be simplified?
• Are the requirements easy to obtain or access?

When you have applied these questions to each step, you can now apply these questions to the entire workflow:

• Is this workflow as efficient as it could be?
• Is this the most intuitive approach to the workflow?
• Is this workflow scalable?

If you have satisfied each of these questions, you should have a pretty rock-solid workflow in place.

The Mechanics of Collaboration

• Community TODO List

The operative word here is conducive. What does that mean, though? How exactly do we optimize our environment for the purpose of achieving our goals? Collaboration is all about working together for a common purpose, opening up a channel in which content can flow between interested parties for the purpose of building something interesting. This content and the tools that make it flow are the mechanics of collaboration. Collaboration is a form of conversation, a reciprocal back-and-forth of communication around a common topic. At the heart of all conversations are at least two people and a:

• Shared language.
• Shared topic.
• Communications channel.

Imagine a normal spoken debate taking place in a London pub. The shared language may be English, the topic could be how effective the prime minister is, and the communications channel is the spoken word (lubricated with a pint of something cold). These simple attributes combine to create a thread of responses, each building on the previous statement. This combination of responses comprises a conversation.

Example: Ubuntu Bug Workflow

Please visit the "Example: Ubuntu Bug Workflow" Wiki, as it provides the context for the Lessons Learned section below.

Lessons Learned

This example reflects a useful approach to help you “build an environment conducive to our wider goals.” Its key themes likely apply to your community:

1. Identify the primary ways in which you collaborate. These are the areas in which your tools and workflow should be as flawless and intuitive as possible. In our example, we identified bugs as a key area.

2. Understand the problem. How does your community understand and engage in the process you are exploring? Which parts of the problem are more problematic than others? What do you want to achieve? In our example, we knew that linking was a problem, and focused on it.

3. Break down the workflow. When you understand your areas of focus, examine the process and ask whether each step is entirely necessary or could be improved.

These three simple steps are all based on the principles of understanding the problem and making a solution that is as simple as possible. Simplicity is a key goal in everything we do with community.