Chapter 4. Processes: Simple Is Sustainable
“Light is the task where many share the toil.”
Ray Kroc was a fairly simple guy. As a small-time salesman in the 1950s, he had moved on from the thrill-seeking paper cup world to sell multimixer drink machines to restaurants across the U.S. His machines allowed anyone with rudimentary operating capabilities to create one of those delicious creamy milkshakes that required the power of a thousand vacuum cleaners to suck it up the straw.
Kroc’s machines were a hit, and it wasn’t long before his path crossed with Dick and Mac McDonald, owners of a small restaurant chain called McDonald’s. A partnership was born, but Kroc’s ambitions went way beyond milkshake-making machines. His ambitions also went way beyond those of Dick’s and Mac’s. Before long, Kroc purchased the chain and started growing his empire.
From such humble beginnings, McDonald’s now serves over 47 million people every day. Kroc, starting with his inventive approach to milkshakes, died with a fortune of over $500 million. Boy, that is a lot of milkshakes.
Love it or hate it, McDonald’s has been hugely successful. Its food is cheap, readily accessible, efficient (in an increasingly busy world), and of typically acceptable quality. Of course, some of you will disagree with the last part, but let’s put any gripes to one side for a moment. I am more interested in the mechanics behind the meals.
In 31,000+ restaurants in over 119 countries, each McDonald’s restaurant serves an average of 1,500+ customers every day. Its menu is packed with products, each of which has its own preparation method, ingredients, and presentation. But let’s be honest: the average McDonald’s employee is not exactly a master chef. Most of the people who work at McDonald’s are untrained, and the training they do get is rudimentary. McDonald’s low cost of staff is a key area in which it competes effectively—but how does it do it?
Like Henry Ford before it, McDonald’s has broken complex processes into sets of steps that almost anyone can replicate. If you were going to cook fries at home, you’d have to consider a lot of variables: the time it takes to heat the oil, how small you need to cut the potatoes, cooking time, draining, and making sure not to inadvertently plunge your hand in the oil (an ever-present risk when I am in the kitchen). McDonald’s has eliminated the need for this range of knowledge by converting the cooking process into a series of simpler steps: unpacking boxes, filling containers, pressing buttons, etc. McDonald’s has perfected process simplification.
The inverse of simplification is complexity, and we don’t like complexity around these parts. Complex processes are ugly beasts, and their effect is to merely build bureaucracy.
You need to avoid this 11-letter word at all costs. Bureaucracy is the enemy in this chapter: it is the vitriol that breaks down the opportunity, potential, and belief that we celebrated so strongly earlier in this book. Great processes blend into the background, functioning as required and as expected. Great processes let people get on with doing real, human, interesting things. Bad processes serve as nothing more than a dartboard for your contributors to throw their frustration at.
Great processes are our aim in this chapter. We are going to assess the many and varied processes involved in your community, break them down into steps, and make them as simple and effective as possible. Processes are everywhere in communities, determining how:
New people join.
People submit contributions.
People collaborate together.
People deal with conflict, and so on.
It is no coincidence that the word “people” is in each of those examples: people are the foundation of community, and for us to ensure these people can work well together, we need to focus on people at the foundation of our processes.
When we (a) know which processes we need to create, and (b) make them delightfully simple, our community members can get on with enjoying the community that they signed up for.
Eyes on the Prize
One of the challenges of writing a chapter about processes is that they are so abstract. The word “process” is unspecific: it describes a set of steps that achieves something. For newcomers to the subject, this is difficult to get your head around without specific examples of processes. This could include the examples we just spoke of: how new people join your community, submit contributions, collaborate, and deal with conflict.
When thinking of how to approach this chapter, as well as the wider book, I am keen to not merely provide you with answers to specific problems. This reminds me of the old Chinese proverb:
Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.
I want to teach you all how to fish. I want the content in this book to help you grow and build best practices that can be applied in a range of scenarios. This absolutely applies to processes.
But this brings us back to our original conundrum: processes can be a little abstract and difficult to understand if not provided with an example. As such, as you read this chapter always consider how you can apply the content to the examples we discussed earlier, such as encouraging new members into your project.
Throughout this chapter we will discuss how to build processes that are smooth and effective, explore what is important to consider when building them, identify our needs, and document and communicate them in your community.
Keeping Things in Perspective
Right now I can imagine that some of you are not exactly exhilarated at the idea of reading a chapter all about processes. I admit that even I, while planning this book, was initially hesitant about devoting a chapter to processes. Some of you may see processes as a waste of time, an overly formal mind game that makes life less fun for everyone involved. Some of you may even go as far as suggesting that to define processes is to limit community and entangle its members in rules. But just invert this oversimplification, and you will be closer to the truth: well-thought-out, simple, and well-documented processes enable your community members to do their real work easily and effectively.
Here is the crux of how we frame this perspective: processes are useful when they become a means to an end. I don’t want to overplay the importance of constructing processes, but I do want to stress the importance of the activities that they implement. In other words, making it easy for new members to join your project is really important, but the process that makes this happen should never overshadow the end goal. A consciousness of processes is good; obsessing over them is bad and breeds bureaucracy. We always need to keep our eyes on the prize.
I raise this distinction for an important reason: building processes is a core activity in governing a group of people. Unfortunately, all too often the act of governing can overtake the goals of the governance. Always bear this in mind when building your processes, and always ensure you are not building processes for the sake of building processes. Not all problems can be solved with documentation and rules.
Building Great Processes
Processes are everywhere. There is a process to withdraw money from your bank account. There is a process to get the oil changed in your car. And of course, any interaction with the government...well, I am sure you can end that sentence for yourself. Unfortunately, many people who interact with processes experience little reward for a lot of frustration.
Processes are like television news: we only ever hear the negative stories. Television news favors murder and accident stories over local charity success stories and animal rescues. In the same manner, the only processes we ever hear about are often problematic ones: people queuing for two hours to mail a package, piles of forms we have to fill out to file taxes, and the hoops we have to jump through to buy insurance. Believe me, even though I have written this chapter, I hate bad processes just as much as you.
Processes that don’t work suck, plain and simple. Some process failures are far more dramatic than others, though, and can have very severe human ramifications. One such example is the product recall. In Process Improvement Essentials (O’Reilly), James R. Persse talks up product recalls and the insights that they offer:
As a rule, corporations like to keep their troubles quiet. They prefer to keep their problems from showing up on the street. It can be embarrassing. And it takes a lot of explanation to a lot of people who probably aren’t prepared to appreciate that these things happen. Nobody’s perfect. Defects happen.
We are all familiar with product recalls, those little notices in supermarkets and newspapers that indicate that something went horribly wrong when the product was created. Recalls are bad for business because they say, very clearly, that the manufacturer’s quality assurance processes don’t work. Whether nuts contaminated a nut-free zone, pieces of glass broke into a large vat of baby food, or a batch of eggs was exposed to salmonella, product recalls point the giant finger of blame in the general direction of the manufacturing process. These recalls not only destroy faith in brands, but cause concern in customers and sometimes even panic.
Bad processes are one thing, but a process that nearly costs people their fingers is something entirely different. Persse shares with us the curious case of the Chevrolet Venture minivan debacle:
Take the Chevrolet Venture for example. This popular minivan ran into something of a quality problem in the late 1990s. At issue was the questionable design of its passenger seat latch. The company received data that indicated maybe the latch had an operational defect. After some study, Chevrolet determined that a general recall of the 1997 Venture was in order. Here is an excerpt from the text of that recall notice: “RECALL NOTICE (1997 Chevrolet Venture): Passenger’s fingers could be severed by latch mechanism that moves seat fore and aft (Consumer Reports 2005).”
Now, as a general rule, severed fingers should not be a part of anyone’s driving experience. What manufacturer would want that picture etched into the brand image of their minivans? Chevrolet no doubt brought its forces to bear. That latch was probably redesigned and re-manufactured against the highest standards, with inordinate attention to detail: test after test, exhausting verification runs, complete assurance of unquestionable integrity. It wouldn’t surprise me if that latch today—almost 10 years later—stands as the world-class epitome of efficiency and safety in seat latch technology.
This was a pretty serious problem, to say the least. The outcome of a bad process (quality control) could have been disastrous. Aside from the obvious safety problems with many recalls, the nightmare goes much further. Products are expensive to replace. Advertising the recall is expensive too. Legal issues are likely to arise from embittered customers. Whether the bad process involves a thousand and one tax forms to fill in or a latch that may sever your fingers, bad processes cause significant harm.
Similar risk applies to communities. When we take a laissez-faire approach to processes, we put confidence in our community at risk. Processes are the conceptual buttons that your community members push to make things happen, and when those buttons don’t work as expected, people get bored and frustrated and move on. On the other hand, if we craft smooth, efficient, and effective processes, our community feels nimble, responsive, and a pleasure to be part of.
Breaking Up the Puzzle
Building a quality process is like taking a road trip. You know where you want to go. You want to take the shortest route, and you want to avoid as many bottlenecks and problems as possible. When you plan your perfect route, you are careful to take the fewest number of roads, take advantage of available freeways/motorways, avoid rush hour, regularly check on current road conditions, and ensure that an In-N-Out Burger restaurant is on the route at regular points (that’s just my personal criterion...).
You should take the same approach to efficiency with your processes. How can you achieve what you want as quickly and efficiently as possible? How can you communicate the journey as easily as possible to new members? How can you ensure your processes are always amenable to current conditions?
Great processes are beautiful creatures, but they need care and feeding to thrive. Our goal in this chapter is to identify these needs and produce processes that exhibit the following criteria:
- The goal of the process is achieved as quickly as possible
The quicker a process ends, the quicker your community can get on with more interesting things.
- The fewest possible steps can achieve the goal
Redundant steps merely make the process feel long and drawn out; let’s avoid that.
- Each step is simple, well documented, and clearly communicated
Each step should be absolutely necessary, and performing it should be simple. A quick technical example: if you need someone to type something in, don’t demand case-sensitivity; it only complicates that step.
- The process is as friction-free as possible
We want to avoid confusion and annoyance, not only with each step in the process, but in the process as a whole.
- Quality is maintained at every step
We need to identify and maintain the different types of quality involved in a process: its accuracy at achieving the outcome, how efficient it is, how well documented it is, how current it is, and how open to change and improvement it is.
Although we will talk about it shortly, simplicity is the foundation of all good processes. As an example, consider how members join your community. How can you develop a process that is as easy as possible to follow and simple to explain to others? Put yourself in the position of a new community member who has no idea how to join your community. How can you learn how to get involved and get there in as few steps as possible? When this is as efficient as possible, you have a much better chance of recruiting new members.
Continuing the example, some communities have incredibly elaborate processes for how people join. They require applications, supporting evidence, membership council votes, signed documentation, agreement to terms and conditions, and more. Some communities are far simpler, merely requiring someone to participate in a discussion. Your community will be somewhere between these two points, and although only your community can really decide where this is, our discussion throughout this chapter should help you determine this.
Building a process
Earlier in this book we created our strategic plan. In it we produced a set of objectives and goals, each of which we broke into steps and documented. This approach is also excellent for building processes, albeit with a different set of criteria.
When you need to build a process for something (such as how members join your community), note down the following criteria:
- Goal
What is the goal of the process? What does it seek to achieve? What is the outcome when the process has been followed?
- Target participants
Who is the process designed for? Is it intended for a particular kind of contributor, such as a developer, documentation writer, translator, or advocate?
- Requirements
What tools, knowledge, and experience must the contributor have in order to follow through with the process? If she does not possess these requirements, how can she obtain them easily? Are these requirements a barrier to entry (such as costing money or limited availability)?
- Steps involved
What are the chronological steps involved in achieving the goal? What could go wrong? Is it possible for people to accidentally ruin a step? How is feedback provided about each step? Who provides the feedback?
- Verification
Who makes the decision about the successful completion of the process? Also, how is it communicated that the contributor has achieved the process?
Let us now apply these criteria to our previous example of a contributor joining a community.
In our example we are the members of a small open source project that is working together on a video game that pits open source community managers against each other with the stylings of Street Fighter II. Naturally I would expect my own representation to be somewhat more muscular and toned.
As an open source project, we want to encourage people to contribute code (such as a patch to crank up my muscles). For developers to contribute, though, we need to give them access to the code repository. Before we give them this access, we need a process that helps them contribute some code that we can assess first, so we can ensure that only capable developers can contribute directly to the repository.
Let’s now apply the set of questions we discussed earlier to this example. Here are some answers:
Goal: To assess developer contributions and if approved, permit direct access to the repository.
Audience: Developers with some experience of the project.
Requirements: Development experience, interaction with the community with regards to software development.
Steps Involved:
Developer can email patches to existing developers or attach them to bugs.
Developer creates an application page on the contributor wiki with:
Name.
Email address.
List of patches contributed and a link to their commit email.
Any additional notes.
Applicant waits for a decision within one week.
Verification: The core development team.
If you are not technically savvy, don’t be thrown off by terms like “patch” or “commit email”; they’re not really important. The value in this example is how it outlines the core structure behind a typical process. Also note that this process does not cover specifically how the existing development team assesses these applications from new developers: that would be its own separate process.
Note
Later in this chapter, we are going to dig into more detail about how to make it as simple as possible for contributors to join your community.
In a few pages we will determine what process needs you have for your community and then apply this formula to those needs. First, though, I want to talk through a few additional important best-practice considerations when thinking about processes in general.
Process Considerations
The art of building effective processes is in not forgetting the big picture when fleshing out the details. Processes get very granular very quickly. It is easy to sometimes get lost in the details and forget some of our wider ambitions.
To complement our approach to fleshing out process criteria, let us now explore some of the key themes that make good processes. These key themes should be at the forefront of our minds while we work.
Simplicity is key
Life is pretty complex, and modern technology seems to exacerbate as much as relieve that complexity. Take the now-somewhat-archaic example of the VCR. For years, thousands tried to set their VCR to achieve a seemingly simple task: to tape a show at a specific time. Unfortunately, many of us failed. We heard endless horror stories of missed tapings of Falcon Crest, Days of Our Lives, and other such travesties (sounds like a blessing in disguise to me). VCRs seemed to just confuse the heck out of many of us. There are similar examples: car entertainment systems, computer software, automated ticketing machines in parking garages, and online banking, to name a few.
Part of the problem is that design and engineering have traditionally not been particularly good bedfellows. This is not a new problem. Way back in 1847, Sir Henry Cole, one of the forefathers of industrial design, expressed his concerns over this problem to The Society of Arts:
Of high art in this country there is abundance, of mechanical industry and invention an unparalleled profusion. The thing still remaining to be done is to effect the combination of the two, to wed high art with mechanical skill. The union of the artist and the workman, the improvement of the general taste of our artificers, and of the workmen in general; this is a task worth of The Society of Arts and directly in its path of duty.
Cole was suggesting that we approach mechanical inventions with the mind of an artist and vice versa. He understood that artists and designers have a fresh approach to how we think and interact with things. He also understood that engineers can build reliable and useful inventions. When we combine this understanding of the human psyche with the ability to build devices, machines become easier to operate and invariably look less like something that I myself would bodge together in my garage.
Examples of simplicity are everywhere. Andy Oram, who has lovingly edited this book alongside Simon St.Laurent, shared one such example of this with me. Andy had a conversation once with a user interface expert about a quiz program he had developed. His interface was good, but could have been better. It worked like this: first he had people create an account and then create and save a quiz. Andy’s user interface mentor suggested he let people create the quiz right off the bat on the first screen. This meant the user could sign up for an account if she decided the quiz was worth saving. This suggested change was a simple example of optimizing a process and removing a barrier to participation. This is exactly what we want to achieve.
Avoiding bureaucracy
While writing this book, I experienced something of a disaster. While talking to my wife one evening about some Ubuntu work I was doing, I was gesticulating and inadvertently threw wine all over my laptop. Seemingly not satisfied with my quota of laptop abuse, a few days later I managed to throw tea all over the poor blighter, too. I, my friends, am a clod. Said laptop complained and refused to switch on. As such, a replacement was needed, so I hopped online and ordered myself a snazzy new machine. And thus the pain began....
In the space of the following week, I was tortured by customer support. Issues with a credit card payment, and need to use another credit card? Problem. I need to register a card and wait 24 hours. Entirely incompetent staff. Want to speak to a supervisor straightaway? Problem. I am entered into a queue, and will get a call in 24 hours. Laptop arrives and fails to switch on.... Can a replacement be ordered automatically? Problem. I have to first wait for a refund, manually reorder the laptop again, and wait for it to be built and dispatched. I was not a happy boy.
I am sure all of you can report similar experiences. Each of these frustrations was caused by bad processes. We learn from such experiences that an organization must not only create a simple process, but set up ancillary processes that kick into action when something goes wrong. The problem during my laptop order sprang from a company that was thinking like a company and not a human; in other words, it set up processes that were convenient for its organizational structure and resources, not responsive to customers.
Many of these problems could have been avoided with feedback. The most important ingredient when building processes is an understanding of people and their expectations. And this understanding requires you to solicit feedback, along with a culture devoted to always improving and refining your processes. When we understand and react to participants’ expectations, processes behave as they expect. Part of the reason why feedback is so important is that it prevents bureaucracy: rules that are maintained because “they are the rules.”
Spread the message in your community that tomorrow may always bring a better way to carry out a current process. Processes provide an excellent opportunity to simplify tasks, tend to needs, and help your community focus on innovating more easily.
Encourage and enthuse your community to question your processes. This feedback will keep your processes on their toes and protected from the dreaded B-word.
Transparency
Another distinctive benefit of feedback is to bring an air of transparency and openness into your community. When people can contribute their thoughts and opinions, and those views get rolled back into community processes, openness is achieved.
All volunteer communities thrive on a sense of openness, because they are associative. These communities are built by people who choose to live their lives there. Everyone who participates in a volunteer community does so because they enjoy it: it is not a job or a requirement. As such, to keep them involved, there needs to be a sense that their input is valuable, and this absolutely applies to their input on how well community processes are working. Ask yourself this question: would you rather live in a community where you can have an impact on the governing rules, or a community in which other people decide?
Unfortunately, not all communities get this right. Back in March 2003, the xFree86 project was struggling with transparency. xFree86 was a free implementation of X, the core windowing system that many Linux, BSD, and Unix systems relied on. Everyone with a graphical interface on those systems was almost certainly using xFree86.
Back then, the processes and procedures that outlined how developers joined the project were minimal, undocumented (or unknown), and restrictive. The directors of the xFree86 Corporation dictated these processes, even though the technical direction and leadership of the project had traditionally been governed by the xFree86 Core Team (comprised of the main xFree86 developers).
One person who was deeply unhappy with this was Keith Packard, a core X developer who was working at Hewlett-Packard at the time:
While the xFree86 Board of Directors is nominally in charge of xFree86, they have absented themselves from governing the project and left that to the xFree86 Core Team. The community is left wondering who is actually in charge of xFree86. As a result, community trust in xFree86 leadership has suffered. Decisions appear to be arbitrary and are not seen to reflect the will of the community. The leadership has no accountability to the community: thus community members have no ability to change project direction and the Board has little incentive to do so. In addition, the lack of clear formal policies has made it difficult to resolve disputes when the usual consensus breaks down.
This breakdown in governance and lack of clear, community-led processes had very real ramifications for the project. Fewer developers were able to join. xFree86 development was slower than expected. Those projects that depended on xFree86 could not progress further due to technical limitations in X, so free operating systems were failing to benefit from the features and performance offered by new generations of graphics hardware. As a critical component in the Linux desktop, xFree86 was holding everyone back. It was a real mess.
Unfortunately, the bylaws of the community stated that any changes in governance had to be initiated by the directors of the xFree86 Corporation. This was a problem. The board members were evidently not particularly responsive or reactive to the concerns of the community, as Packard noted:
xFree86 has the trappings of democracy, but the community has no voting rights and no elections are held.
Ultimately, the desire for openness and transparency won out. On January 22, 2004, the X.org Foundation was formed. The new foundation brought the open governance and open processes that are common in open source to X. Since then, the X Window System produced by the X.org community has thrived.
These risks with transparency can happen to any volunteer community. The solution to this is simple: involve your community at every step of your community growth. Involve them in the strategy, the processes, the governance, the execution of these decisions, and more. Have public communications channels and public meetings, and instead of questioning whether something should be public, question whether it should be private. When we work together, the world feels a very open place.
Assessing Needs
Earlier in this book we explored many of the best-practice aspects of community building and compiled a TODO list of these elements. One of these items rather conveniently relates to our current discussion of processes.
Effective environments are built on effective processes. As a community leader, your goal is to build an environment that offers rich opportunities and is simple to engage with. So you need to figure out which processes you need in your community and apply your recipe and best-practice concepts from earlier in the chapter.
Processes can be broadly divided into three primary categories:
- Environment and strategy
This is a continuation of the strategy that we built earlier: the general concepts that apply to everyone in your community, such as milestones, direction, processes that define how people collaborate, and external feedback.
- Infrastructure
The technical nuts and bolts and tools of your community: the day-to-day facilities that your community members require to get things done.
- Governance
The governing bodies, legislation, rules of engagement, and other more political components required to organize and govern your community.
Each of these three areas is of significant importance in building a strong community, and I have devoted a chapter each to infrastructure (Chapter 5) and governance (Chapter 8) later in this book. Each of those chapters helps you build effective processes in those respective areas using the best practices described in this chapter.
So let’s now talk through some of the environment-related concepts that are important in our community. This will give you some handy examples that you can apply to your own community.
Community Cycles
Most communities, particularly collaborative ones, require some kind of planning cycle. Whether you are working toward a software release, a conference, a local event, or something else, planning is key.
Many of these objectives are reoccurring. Software regularly has releases. Events regularly occur. In addition to this regularity, there are regular milestones that need to be completed to achieve the objectives.
One such example is software. Most software releases adhere to the following broad set of milestones:
Development begins.
Feature freeze.
User interface freeze.
Beta freeze.
Beta release.
Translations freeze.
Release candidate.
Final release.
Another example consists of the milestones involved in planning a local community conference:
Planning begins.
Call for papers/exhibitors opens.
Final speaker list chosen.
Final exhibitor list chosen.
Schedule published.
Venue equipment finalized.
Event begins.
For each of these two examples, the milestones combine in chronological order to define a cycle. If you have similar milestone-leading-to-goals requirements, I recommend that you produce your own cycle.
Leading by example: Ubuntu
Ubuntu releases a new version every six months. Each release cycle involves a number of tasks: updating the toolchain, syncing and merging with the Debian release upon which Ubuntu is built, deciding on direction at the Ubuntu Developer Summit, scheduling freezes, releasing alphas and betas, and other elements.
At the beginning of every release cycle, our release team documents the release cycle on the Ubuntu Wiki. As an example, the 9.04 Jaunty Jackalope release cycle was documented at https://wiki.ubuntu.com/JauntyReleaseSchedule.
The release team broke the cycle down into a number of weeks, dividing the weeks into sections by month. Each week is placed into a table that has “Week Number,” “Date,” “Status,” and “Notes” columns. Here is a snippet from the March part of the Jaunty plan.
March 2009 | |||
Week number | Date | Status | Notes |
18 | March 5 | User Interface Freeze Artwork Deadline Two | |
19 | March 12 | Alpha 6 | |
20 | March 19 | Beta Freeze Final Artwork Freeze | Rebuild Test |
21 | March 26 | Beta Release Docs String Freeze | Beta |
An important component that enables the planning cycle is knowing how long each task should take to complete. When you build your own cycle with your community, make a fair assessment of how long your tasks should take, and build in some redundancy for delays.
When your cycle is complete, you should ensure that it is published and available to all your community members. An excellent way of doing this is to place it on a wiki.
The Gates of Your Community
Now let’s take a look at another item on our TODO list.
Attracting new contributors is an essential part of any community. Earlier we used this item as an example in fleshing out a description of our process. I want to now explore this important item in more detail.
In attracting contributors, our goal is not merely getting the word out; it is about getting the word out to the right people and ensuring that they can join us in achieving our goals.
In this work we have two primary outcomes that we want to achieve:
To ensure that the on-ramp from consumer of buzz to full-fledged community member is as smooth as possible.
To attract community members who will demonstrate commitment and a willingness to work toward the goals of the community.
The first point may seem obvious, but the second is more subtle. What we want to avoid are drive-by contributors. These are people who join a community for a few weeks, you help them get up and running, and they then get bored and move on.
Drive-by contributors are expensive, not necessarily financially, but in terms of time. Contributors often require a certain level of (wo)manpower. The community responds to their questions and provides the help, guidance, training, and mentorship needed to get them on their feet. If these contributors receive this assistance and fail to deliver anything of value, they become expensive propositions.
Animal welfare communities have dealt with this for years. Cristina Verduzco is the volunteer/outreach manager for the East Bay and Tri-Valley SPCA (http://www.eastbayspca.org/). Cristina is responsible for recruiting, training, and managing volunteers. She is responsible for all facets of the volunteer program, coordination and planning of multiple events, and coordination of mobile adoptions.
Retention is important for animal welfare communities. Not only do volunteers need to be trained in how to care for the animals, but bonds are developed with the animals they care for, too. It is in the interest of the animals to maintain sustained contributions: they feel more comfortable around familiar faces. Cristina is fully aware of the biggest risk to retention:
Retaining volunteers will always be a problem for any animal welfare organization. While the work is rewarding, it can also be difficult. We are fortunate that our euthanasia rates are lower than almost all other shelters, as we don’t euthanize animals for lack of space. While it is common that issues around euthanasia tend to be a big reason for people not to return, we don’t see that quite as often at our shelter.
Every community is strained by push and pull forces that will affect your ability to retain volunteers. This will apply equally in your community. For the SPCA, euthanasia is clearly a blocker for many to get involved. What is your equivalent blocker? This could be difficult personalities, suboptimal working conditions, hugely complex processes and technical procedures, or anything else.
You should identify these blockers and ensure you have resources to help people over the hump. Importantly, you should not downplay or cover up the difficulties in your community, but until you can fix the problems (which you should seek to do as a matter of priority), it is entirely reasonable to make those difficulties as pleasant to navigate as possible.
You should also focus on the attracting forces that bring people to your community while again ensuring that you communicate a balanced perspective. At the SPCA, the clear attracting force was kittens and puppies, but Cristina is keen to balance this with the reality:
Let’s face it—playing with kittens and puppies sounds fun until you realize there’s cleaning and training involved, and sometimes that deters volunteers. Sometimes people have every intention to commit, and down the line realize their schedules don’t work out.
These long-term contributors are the real rock stars in your community. Cristina and her colleagues rely on their “angels” heavily:
Fortunately, there are always those people who come in, fall in love with the work, and stay for the long haul. Some of our volunteers have been with us over ten years, and they come every week without fail. We refer to them as our “angels”. Our volunteers are the reason shelter animals don’t go crazy in confinement, and for that reason we are indebted to them.
You have an enormous opportunity to find your own “angels” if you offer enough enthusiasm and excitement to pique interest in your community, give them a realistic set of expectations about the work involved, and ensure their experience is positive.
Before we move on, I want to be entirely clear when I say “long-term contributors” here. You should not expect your contributors to be working full-time for your community. Your focus should be on sustained contributions, no matter how long each contribution lasts. If your contributors put in three hours a week every week, that is an excellent gift to your community. This gift is also far better than two days of frenetic full-time contribution and then nothing else.
Retaining contributors sounds complex, but is thankfully pretty simple. If you want people to stick around, you need to offer them a regular sense of achievement. Your community members need to feel that (a) they are productive, (b) their contributions are appreciated, and (c) that (a) and (b) happen repeatedly.
This is particularly important for new contributors. When someone first expresses interest in joining your community, they need to follow what I call the contributor ramp:
Identify an area in which they can contribute.
Learn the skills required to contribute.
Know which specific task to work on.
Know how to submit their work.
When you start attracting people to your community, you are encouraging them to begin interfacing with this process. As such, you need to make sure you have all of the above in order before you even make a peep. The most logical home for this information is on your website.
Assessing Contributors
Many collaborative projects embody some kind of access control. In a typical open source project, those who can contribute code are restricted, and developers are assigned a username and password to contribute code to the repository. The reason is simple: you don’t want just anyone changing the project. The integrity of the code base is essential. You always want your code to run, be as error-free as possible, and maintain consistent coding guidelines. If access were entirely open, those with malicious intentions or error-prone (in)abilities could introduce bugs, defects, and security flaws to your project. Having a vetting process is important to ensure that your developers can be trusted and will demonstrate this level of quality.
As we briefly discussed earlier in this chapter, it is important for us to figure out how new potential developers can gain access to the project. If I want to contribute to an open source project and am unknown, how do I prove my abilities?
The first task is assessing what your expectations of quality are. For many open source projects, they are relatively simple:
A reasonable knowledge of programming; the contributor should not be making the obvious mistakes that new developers make.
A familiarity with the code base and coding conventions.
A regularity of contribution.
Although the implementation of these expectations involves infrastructure technology (bug trackers, source control systems, etc.), which we defer discussion of until later in this book, we can take a high-level view of how some of these processes work.
Reviewing new developers: In depth
Ad Hoc Peer Review is common in the open source world. Here is how it works: you have an existing member of the community review a new contributor’s proposed contribution, and if it is acceptable, the existing member will commit it on the new contributor’s behalf.
As an example, imagine Adam would like to fix a bug in the OpenOffice.org project. He grabs the code, programs a solution to the bug, and then sends an existing OpenOffice.org developer the fix. That developer (let’s call him Michael) then reviews the fix, and if it is suitable, he commits the fix to the main OpenOffice.org code base.
Typically this process would be repeated until each proposed contribution from Adam is almost certainly going to be accepted by Michael. At this point, Adam would be given direct developer access to the source code repository.
A range of projects use this approach. One such project is Jokosher, which was mentioned earlier in Chapter 2. When the project first started, a new contributor called Laszlo Pandy wanted to get involved. He joined the IRC chat channel to express his interest and was asked to submit some patches (small bundles of code changes). To make this as easy as possible for new contributors, we had written a web page that explained how this worked.
I myself reviewed some of his patches. With each one, I provided him technical feedback: areas that worked, elements that needed fixing, etc. When Laszlo’s patches were of sufficient quality (which required only minor adjustments), I committed them for him. After three or four patches, every one was excellent. At this point we gave him direct access to the Jokosher repository. As a bonus piece of Jokosher trivia, Laszlo went on to become the leader of the Jokosher project.
There are a number of requirements for this process to work:
You need to clearly explain in what form new contributors provide a contribution. Should this be a patch? An email? A document? Explain what is required.
Where do new contributors send their contribution? To a mailing list? Mention it on IRC? Email a specific person? Attach it to a bug report?
Your community must be able to access these new contributions and have existing, experienced contributors provide feedback. It is important that this feedback is not held up due to having only a limited set of contributors who are able to provide it. Every contribution should be seen as a gift, and as such should rightly expect feedback, even if this feedback is just “this is excellent work, I have committed this.”
There needs to be a method of tracking these recurring contributions. If a new contributor has contributed three or four excellent patches that have been committed with few or no changes, you need a means of identifying this recurring quality. This could be as informal as some core contributors keeping a mental note of the new contributors, or as formal as maintaining a written log of contributions.
Although this approach has been described here within the context of providing code contributions, this could equally apply to other types of contributions, such as documentation, art, and translations.
For nontechnical projects, a similar approach can involve simply reviewing prior work by the contributor. If you are organizing a local community event and you want a contributor to do the art for the brochure, you could ask him to produce some initial drafts, make sure they’re acceptable, and then accept the contributor as the brochure artist.
Unfortunately, for some larger communities (particularly large open source projects), the previous approach is unsuitable. This can be due to a number of reasons:
The technical requirements involved for the new contributor are too complex to be assessed in a loose and ad hoc way.
There are too many new contributors submitting content for the existing developers to assess in a timely manner.
The project is hugely popular, touching thousands or even millions of users, and as such, granted access needs to be more rigorously assessed.
Although the core technique of reviewing proposed contributions does not change with a more formalized approach (having people check a contribution before it is committed), what does change is how you track and review those contributions.
Let’s look at an example. In the Ubuntu community, we have a little more formality in how new contributors can gain access to one of our key repositories, Universe. Our guiding policy has always been that new contributors should demonstrate a significant and sustained contribution. That is what we seek to assess in new contributors.
The Universe repository is a large collection of applications that are packaged by volunteers. These applications are not officially supported by the Canonical technical support service, and they don’t receive security updates. The team that works on these packages is called MOTUs (short for Masters of the Universe). The MOTU community is led by the MOTU Council, a small group of well-respected MOTU contributors.
Although more formalized, the process is still relatively simple:
New contributors make their contribution by attaching a patch to a bug report. They then subscribe the ubuntu-universe-sponsors team to the bug report. The collection of bugs subscribed to that team is called the Sponsorship Queue.
The team looks at each of the patches, reviews them, offers feedback, and, where suitable, uploads the changes.
This process repeats a number of times to demonstrate the sustainability of contributions from a given contributor.
After a number of contributions have been made, an existing MOTU will often recommend that the contributor apply for MOTU approval.
Candidates prepare a wiki page outlining the contributions they have made to the project and also some endorsement statements from existing MOTUs to approve their application.
The application is reviewed by the MOTU Council and then approved where appropriate.
The MOTU community’s approach has been refined over the years. At its heart, new contributors add their contribution to a queue, go through review, and then apply to the MOTU Council. The only differences are the sponsorship queue and the approval process, which make the approach more formalized.
Managing Feedback
Gathering feedback from the outside world is an often-overlooked but important facet of a strong and healthy community. Feedback is important for providing you with others’ perspectives, and these perspectives can help identify opportunities, problems, and areas that need renewed focus. It is this feedback that tells you what people outside your community think of your goals, ambitions, and progress. As such, feedback is a positive double-edged sword: not only does it provide pleasant confirmation of things we’re doing right, but it also reveals and focuses our minds on areas to improve. Finally, a good process for handling feedback can improve all your other processes, as I explained earlier in this chapter.
Unfortunately, many community leaders view feedback as a nuisance, and disregard it if it challenges their work and the norms of the community. This is the wrong perspective to take. Feedback instead offers us an incredible opportunity for improvements in how our community functions.
None of us are perfect. None of us get things right every time. Even the greatest community leaders in the world—and the most intelligent and hard-working community members—get it wrong sometimes. But being wrong is not black and white. In many cases we craft interesting and inspiring initiatives, but we sometimes focus on the wrong things or overcomplicate matters. Feedback helps zone our minds in on which elements to fix.
This happened to me recently. Back in February 2008, my team and I were thinking of methods to improve how we handle our list of bugs in Ubuntu. As Ubuntu has grown and is now used on millions of computers around the world, the list of reported bugs has grown, too.
After fleshing out a number of different possible approaches and plans, we announced a new scheme called 5-A-Day. The idea was inspired by the popular meme of eating five portions of fruit or vegetables every day to keep healthy. I wanted to apply this concept to software bugs: encouraging everyone in the Ubuntu community to work on five bugs every day. This would make our bugs list and resultantly Ubuntu healthier, too.
The response was stunning. Many contributors got involved, and thousands of bugs received attention. Many of our contributors didn’t stop at five bugs, though; they were often nailing upwards of 20 or 30 a day. Some were even hitting 100 a day. These people were bug-squashing machines.
Ten months later, at the Ubuntu Developer Summit in California, I scheduled a session to review 5-A-Day. I was keen to gather feedback and opinions about the initiative and how we could improve it. In the session, a friend of mine called Robert Collins raised a valid point: in measuring 5-A-Day, we were measuring the wrong things.
Robert argued that 5-A-Day should not be recognizing those who were smashing past the five-bug target for each day and hitting the high bug numbers. He felt that in keeping with the Ubuntu ethos of significant and sustained contributions, 5-A-Day should instead cap the number of bugs at five per day and instead track how long people were maintaining their daily 5-A-Day. Robert felt that it was more valuable if we knew that a contributor had consistently worked on five bugs a day for a month, instead of doing 155 bugs in a day. He was right. Sustainability is an essential component in community: more bugs get fixed, people consistently set a good example for others, and we build a long-term contributor base that is regularly working on bugs as opposed to localized spikes of interest.
In this example, our request for feedback at the Ubuntu Developer Summit resulted in a valuable piece of insight, one that may never have occurred to my immediate colleagues or to me.
Gathering feedback
Feedback can be collected in many ways. The simplest and often most effective way is to set up an email address that forwards email to a number of core community members. A simplification of this approach is to set up an account with a free email service and give each of your core members access to the account. This approach is excellent for gathering general thoughts, concerns, and opinions about the community that often reflect on processes.
Another alternative is to set up a public mailing list that people can submit feedback to. This solution is not the most suitable for single-shot chunks of feedback from someone. Mailing lists are designed for discussion, so you should really use mailing lists only if you want people to submit feedback and have a discussion afterward. Another downside of mailing lists is that they require people to sign up, and these members will also receive all email to the list. Someone who just wants to give you a quick chunk of feedback likely won’t want to see what everyone else is submitting to the list.
Another possibility is to use a blog. You could post entries to the blog to request feedback and allow readers to provide their feedback in the comments. Remember that all feedback here will be public. You may not want to have everyone and their dog see this feedback (although it is an impressive message of transparency if you do). What’s more, remember that search engines will index this potentially negative feedback, showing it to everyone who searches on your project name, even if you’ve since addressed the problems.
The most productive approaches I’ve used for gathering feedback have been surveys and one-on-one discussions. We cover surveys in more detail in Chapter 7; they are an excellent means of gathering focused feedback around specific areas of interest. I have used them extensively in my work, particularly online surveys, and they have always gathered excellent results.
Whichever of these techniques you decide to use, you should always augment them with some direct one-on-one discussions. Find people who have an opinion about the process you are investigating, and get them on the phone, send them some specific questions over email, or get together to discuss their views over a coffee. This direct feedback is often very valuable; just remember that feedback will always be tinged with opinion and potential exaggeration, and one-on-one discussions are the most likely candidate for this.
Getting Buy-In for Your Processes
So far we have discussed many of the best practices for building simple yet effective processes. We have talked about simplicity, transparency, avoiding bureaucracy, assessing needs, and more. Processes don’t mean anything, though, unless your community (a) knows about them, (b) understands them, and (c) uses them.
At the beginning of this chapter, we likened processes to machines and waxed lyrical about how interface and industrial design have made devices easier. We noted that we should apply the same logic to our processes. We can continue our analogy beyond the development of processes (akin to the devices) and also apply it to their packaging and distribution. How can we make our processes as easy to understand, discover, and use as possible?
Document Them
The first step in making a process work for your community is to ensure it is documented. The goal here is efficiency. Sure, anyone can write a detailed list of steps outlining how a process works, but who wants to read paragraphs and paragraphs of text? The documentation behind a process should be as close as possible to a cooking recipe: do this...do that...get this result. The emphasis here is on quick, clear, straight-to-the-point directions.
Processes are fundamentally a collection of steps with an outcome. Documenting them is similar to Ikea’s instructions for putting together a shelving unit. How can you tell the user how to achieve the outcome as easily and effectively as possible?
When Ikea does this, it uses only pictures, presumably to avoid translating instructions into multiple languages. Although I would recommend using text for most communities’ processes, the Ikea model is cathartic and helps focus your mind on the right goal of reducing clutter.
To get you started, let’s get introspective for a while and document your own steps for writing a process:
First, write down the end goal of your process. What does it achieve?
Now, in numerical and chronological order, write down each step in your process, using a single word to describe each step.
Finally, for each word, write a single sentence that clearly explains what is involved in the step.
As an example, the following could be used to develop a process for a new developer contributing a patch to a project:
| GOAL: Achieving contributor access in the FooBar project. |
| PRODUCE: Produce a patch with a new feature or bug fix that can apply to the latest development version of the code. |
| SUBMIT: Send the patch to the FooBar project mailing list outlining what it does. |
| WAIT: Wait for feedback on the patch and, if required, make adjustments. Otherwise, the patch will be submitted. |
| REPEAT: Repeat the above steps until a developer considers your contributions consistent enough to offer you direct access to the repository. |
When following through with this approach, always read and reread each step, and assess how easy it is to understand. Is it written concisely? Does it use too much jargon? Would it be suitable as an elevator pitch?
Make Them Easy to Find
Processes don’t have any value when no one knows that they exist. In addition to ensuring that your processes are clearly written, you should work hard to ensure that they are discoverable. Our goal here is to ensure that community members can find our documented processes easily.
This is a two-step approach:
You need to put your documentation somewhere online that people can refer to.
You need to inform your community about additions and changes to the documentation when they happen.
The first step involves putting your process somewhere accessible. If it makes sense, you should put it with the rest of the strategic documentation that we discussed earlier in the book. Discoverability is the key here, though.
As an example, if you have a process that new contributors should use to gain repository access, you should make sure that new contributors can find it. This kind of documentation should not be buried in a wiki somewhere. You should assess where your potential contributors are reading documentation and where they are likely to look to find your processes. Again, plenty of feedback can ensure you make the best decision here.
The next step is announcing the new process documentation to your community. Earlier in this book, we discussed communication channels within your community, and you should use these channels to announce this documentation and encourage your community to make use of it.
When you announce your processes, you should include the following details:
The problem that you sought to solve.
A single paragraph overview of the process and how it works.
A link to the online documentation that explains how the process works.
A final paragraph that strongly encourages the community to make use of the process.
When announcing new processes, you should tread carefully. You should expect that your members, suffering from the same fear of rigidity and rules I mentioned at the beginning of this chapter, will roll their eyes at the concept of a new process being announced. Your goal is to have them entirely on board by the end of the announcement. Use loose and friendly language, and make them understand that the process is really necessary and not merely an exercise in bureaucracy.
Using Your Processes
With the process documented and announced, the final step is to encourage your community to make use of it. Documentation and announcements are no guarantee your community will make use of a process. In my experience, every process needs a certain amount of manual pushing and poking to become the norm.
Communities generally follow by example: members look toward other people to engage with processes before they do it themselves. You need to put a few examples of successful use of each process in place as a head start to get the community to accept the processes.
A useful approach is to pick four or five key community members and ensure that they are fully behind the process that you have announced. You should regularly check in with these members to ensure that they are making use of the process, and when they are not, you should check why and remind them where needed. You should also encourage these key members to spread their best practices throughout the community.
You should also identify incidents that act as opportunities to reaffirm the purpose of the process. This could be handled in two ways. On one hand, you should find success stories: examples that used the process with very positive results. These examples are always fantastic to show off. On the other hand, when someone doesn’t follow the process and things go wrong, you can use it as a chance to remind your community about the purpose of the process. Do tread this line with caution: you should absolutely not show up your community members in front of others, and you should try not to climb up on your high horse and send out an “I told you so!” message.
Process Reassessment
Processes are living, breathing organisms. They are typically based around current conditions: the current level of contribution, demand, expectations, and goals. They are the clear plastic film that wraps around the assets and members of your community. As the assets and members adjust, so should the processes.
At the start of this chapter, we firmly established that unchanging processes cause bureaucracy. Processes that no longer map effectively to the people who need to use them cause bureaucracy. Our whirlwind tour of process best practice would not be complete if we didn’t discuss how we can best evaluate our processes and make changes where appropriate, thus avoiding the dreaded claw of bureaucracy.
Process reassessment has become a staple part of each Ubuntu release. The Ubuntu community has a huge range of processes, initiatives, governance structures, and more. Each of these facilities was developed to serve a specific purpose, but as the community has grown and changed, these purposes and processes have needed to change, too.
An example of this was a change in how Ubuntu members have traditionally been approved. Anyone can be a member under the premise that they have demonstrated a significant and sustained contribution to open source. Traditionally, the way this assessment was made was that the candidate would first produce a wiki page outlining these contributions. The next step would be to attend a Community Council meeting online in which the council would discuss the application and vote. A majority vote would approve the member.
As the Ubuntu community continued to grow, this process became increasingly overstretched. The vast majority of Community Council meetings were devoted to approving members, and meetings were dragging on for nearly three hours. At an Ubuntu Developer Summit we identified the problem and proposed that we set up a series of regional subcouncils. We planned to set up a council in the Americas, Europe, and Australasia, and these would take over the task of approving members.
The new councils were formed, and subsequent membership applications have been uniformly more efficient. This has not only benefited prospective members, but it has meant that Community Council meetings have been more focused on governance issues as opposed to merely approving members.
These kinds of process reviews used to occur on an ad hoc basis in the Ubuntu world, but we have since tied them to regular timeline. We now reassess all processes at the beginning of a cycle, and many of these reassessments occur at our biannual Ubuntu Developer Summit. This provides an excellent opportunity to gather feedback (of which we identified the importance earlier in this chapter) and discuss better alternatives.
Note
The problem of overwork and delegating that work to other bodies in your community is part of governance, and we discuss this in detail in Chapter 8, cunningly named...Governance.
Building Regularity
With your community, you should schedule regular process reassessments. You should schedule a time in which your community can come together to determine how to improve on these underlying structures and processes.
How you do this is really dependent on your community. For a small local community, why not organize a series of meetings in a coffee shop or at someone’s house? For an online community, a series of scheduled sessions on an online chat network such as IRC is often effective. Alternatively, you could organize a more formalized event for your community, akin to what we do with our Ubuntu Developer Summit.
However you choose to organize this reassessment, you should ensure the following:
The events should be accessible to your community members. They should preferably incur as little cost as possible, and be within reasonable reach. Organizing a reassessment in Jamaica when your community is based in Northern England is not practical.
The events should be open to all of your community members, and you should explicitly state this when promoting them. You should clearly communicate that everyone is welcome to join in and provide feedback about how to improve how the community runs.
Ensure a sensible level of representation. Feedback sessions with 2 or 200 people are not valuable. Sessions with 10–30 people offer real opportunity to achieve some conclusions.
Ensure that you begin organizing these sessions with plenty of notice, particularly for physical meetings.
When advertising these sessions, you should make them as attractive and practical as possible for your members. Don’t describe it as a “governance and process review” but instead as “how to improve our community.” Make sure that your announcement welcomes everyone, and ensure it underlines how everyone can have an impact. Here is an example:
| Improving Our FooBar Community |
| 1st–3rd Sep 2009 – 5pm–7pm UTC – #foobar on Freenode IRC |
| Ever since the beginning of the FooBar project, we have all worked hard to produce a rock-solid implementation of Bar, and we have seen many new contributors join our stunning community. |
| This range of sessions is designed for us to come together, share experiences and feedback on our processes and methods of working in our community, and see how we can make improvements that benefit everyone. Everyone’s participation is not only welcome, but encouraged! |
When you have scheduled these reassessment sessions, you can build an action plan of what to discuss and how you discuss it. In many of these sessions there is a potential for the discussion to wander off at a tangent. It is therefore important to have a firm idea of what to discuss and what the core issues are.
I recommend following these steps to carve out a method of handling these sessions:
First, make a list of all of the processes that are involved in your community. This should cover topics such as how people get involved, how you work together, how teams work, etc. I recommend you do this in an online document, such as a wiki page.
For each process, note down bullet points for the feedback that you have heard, both good and bad.
Now look at the full list and reorganize it into what you consider priority order. This is most typically driven by which processes are causing bottlenecks and problems in your community.
Now inform the wider community of the list and ask people to either edit the list directly (if they can, such as with a wiki) or to submit feedback for you to add to the list. You should ask for feedback about the processes and also which processes they consider the most important to discuss. Give them a deadline for feedback that is before the reassessment sessions. Merge this feedback into the document and reprioritize the list based upon consensus.
This list is your agenda for the meetings. When you get together with the community, pick the top processes and discuss them in turn. Communicate the good and bad feedback with the community, and focus the discussion on coming up with modifications to the processes that may be an improvement. Always keep these discussions focused on achieving outcomes; they can quickly degenerate into fruitless conversations.
When you reach consensus on changes to these processes, you should ensure that the changes are noted down in the session. These notes provide a TODO list of changes to your process documentation. Remember that each time a process changes, you should announce it to the wider community, just as you did with new processes.
Moving On
At this point, we are making some real progress on our journey through community. We have a strategy and a direction, and we have identified how to build strong processes for many aspects of our community. Now it is time for us to get the tools of collaboration in our community’s hands. We need to put the foundations in the ground that our community can use to build great things. It is time to talk infrastructure....
Get The Art of Community now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
