“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 selling multimixer drink machines to restaurants across the US. His machines allowed anyone with rudimentary operating abilities to create a delicious, creamy milkshake that was so thick it 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 that of 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 and Mac. Before long, Kroc purchased the chain and started growing his empire.
From these humble beginnings McDonald’s continued to grow, and 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 typically of acceptable quality. Of course, some of you will disagree with that last part, but let’s put any gripes to one side for a moment. I am more interested in the mechanics behind the meals.
With 31,000+ restaurants in over 119 countries, McDonald’s has an average of 1,500+ customers every day in each of its establishments. Its menu is packed with products, each of which has its own preparation method, ingredients, and form of 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 in terms 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, how much salt to sprinkle on top of the fries, and how to avoid inadvertently plunging 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, and so on. 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 with one another
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 that these people can work well together, we need to focus on people as the foundation of our processes.
When we (a) know which processes we need to create and (b) make these processes delightfully simple, our community members can get on with enjoying the community that they signed up for.
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 accompanied by 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 our community.
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 so 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 that you are not building processes for the sake of building processes. Not all problems can be solved with documentation and rules.
Shortly after I joined Canonical in 2006 I underwent an experience that changed the way I saw my role as a community manager and how I build effective processes.
I was working at home one day when I got an email that told a stunning story. The sender was a kid (unfortunately, I can’t remember his name) who was living with his family in a remote region of Africa. Some time ago some visitors had come to his village and these visitors had laptops that were running Ubuntu (the software we produce at Canonical).
When the kid asked these people what was on their computers and they mentioned Ubuntu, it immediately resonated: the word ubuntu is an ancient African word meaning “humanity to others.” This piqued the kid’s interest and he asked for more information about the software. They then told him how the software was entirely open and created by a global community who worked together to create software that people could share with one another. Although the kid had spent little time in front of computers (he didn’t own one and had no access to the Internet), he was absolutely fascinated by the premise of Ubuntu and open source and this culture of sharing. He felt compelled to participate.
He told me that, to earn money, on weekdays he would do odd jobs and bits of work around his village when he was not at school, and then on the weekends he would walk three hours to the nearest town and spend his money in an Internet café, where he would pay for an hour’s worth of Internet time and use it to contribute to Ubuntu. After his hour was up he would walk three hours back to his village, excited about his contributions. He did this every weekend and told me that all week he would look forward to the weekend to contribute to Ubuntu.
I was moved by this email. Not only did it demonstrate the sheer humanity and good nature of this kid, but it also demonstrated how powerful inspiration and community can move people.
Importantly, though, and related to this chapter, it gave me a new way to define and assess my work. My job was simple: to help that kid get the most out of his hour. If he was spending his week earning money to contribute to Ubuntu, and was willing to walk six hours in one day to contribute to our community, it was my responsibility to help him not only enjoy his hour, but also have few, if any, obstacles and barriers to overcome in order to participate. This meant ensuring that the processes that were part of Ubuntu were slim, efficient, and designed to help our contributors achieve great things.
Processes are everywhere. There is a process to withdraw money from your bank account. There is a process to change the oil in your car. And of course, any interaction with the government…well, I am sure you can end that sentence 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 accounts of murders and accidents 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 do.
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), author James R. Persse talks up product recalls and the insights 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 also 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 they involve 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 great to be part of.
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 that 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 also 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.
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 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 entry fees 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 fail to complete a step? How is feedback provided about each step? Who provides the feedback?
- Verification
Who decides when a process has been completed successfully? Also, how is successful completion of the process communicated to the contributor?
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 on a video game that pits open source community managers against one another with the stylings of Street Fighter II. Naturally I would expect my own representation to be somewhat more muscular and toned than the sad example of my real body.
As this is 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, they need to have 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 to this example the set of questions we discussed earlier. Here are some answers:
Goal: To assess developer contributions, and if approved, permit direct access to the repository.
Audience: Developers with some experience in the project.
Requirements: Development experience, interaction with the community with regard 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 and 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.
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.
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: 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 worthy 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.
While writing this book, I experienced something of a disaster. As I was 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 also throw tea all over the poor blighter. 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, 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 also 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 like 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 participants expect them to. 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.
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. People who participate in a volunteer community do 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 (composed 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 (see http://www.xfree86.org/pipermail/forum/2003-March/002165.htm):
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 (see http://www.xfree86.org/pipermail/forum/2003-March/002165.html):
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 communication 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 like a very open place.
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 require 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 areas is of significant importance in building a strong community, and in this book I have devoted a chapter each to infrastructure (Chapter 5) and governance (Chapter 10). 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.
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 is chosen.
Final exhibitor list is chosen.
Schedule is published.
Venue equipment is finalized.
Event begins.
For both of these 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.
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 a 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 down the cycle 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 to do this is to place it on a wiki.
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 to get 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 subtler. 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. 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 they also develop bonds with the animals they care for. It is in the interest of the animals to maintain sustained contributions: they feel more comfortable around familiar faces. Cristina told me she 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 that 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 that 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 (a) that they are productive, (b) that 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, she needs to follow what I call the contributor ramp:
Identify an area in which she can contribute
Learn the skills required to contribute
Know which specific task to work on
Know how to submit her 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 your website.
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 to assess 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.
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 reviewed some of his patches. With each one, I provided him technical feedback: areas that worked, elements that needed fixing, and so on. 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? Post it 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 contributions, 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 members who work on these packages are 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 patch, 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.
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 to improve how our community functions.
None of us is perfect. None of us gets 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 a few years ago. 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 stay 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 bug 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 upward 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 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.
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 her 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 8; 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 through 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.
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 design and industrial design have made devices easier to implement. 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?
The first step in making a process work for your community is to ensure that 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?
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 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 that you make the best decision here.
The next step is to announce 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 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.
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 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 the 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.
Throughout this chapter we have discussed how to build great processes that are focused on accomplishing things effectively and reducing the level of bureaucracy involved in the community (screw you, bureaucracy). These processes can be applied to anything that involves any kind of structure or deliverable outcome, but I want to spend a little time focusing on a very specific family of processes that you will want to get right: the on-ramp.
The on-ramp is the set of steps and processes that are involved in helping someone to get up and running participating in your community. While the term on-ramp has been used for some time, there is little consistency or best practice when it comes to what actually constitutes an on-ramp.
Over the years I have developed my own approach to the on-ramp and a set of steps and processes that not only help people to participate, but to also gain the skills they need and to feel accomplished and celebrated in their contributions. As I have developed this standard approach I have applied it to a range of different communities with good results.
I define the on-ramp as shown in Figure 4-1.
Figure 4-1. An on-ramp is a useful means of defining the different milestones in how a community member learns how to participate in your community.
In my on-ramp there are four steps, each of which is important in the community member collaboration experience. They can be summarized as follows:
- Identifying the on-ramp
For a community member to be able to participate, he needs to know he can participate. We need to be able to reach out and make it clear that collaboration and contributions are not only possible, but also actively encouraged.
- Developing knowledge
With any kind of collaboration a set of skills and knowledge is required in order for people to take part. As an example, if you want to write documentation, you need to know how to write the documentation, how the tools work, and how to contribute your work to the community. We want to make this skills acquisition process as simple as possible.
- Determining contributions
When you know you can participate and have the knowledge to do so, you then need to know what to work on. Which areas need participation and contributions? Which problems need fixing? We want to have a solid set of things that people can pick up and do.
- Growing kudos
Finally, when a community member has contributed something to the community, you want to ensure that he feels a sense of appreciation (what I call kudos) for his contribution.
These four steps in the on-ramp not only cover the timeline of the contributor experience (learning that you can participate, gaining the knowledge to do so, knowing what to work on, and having your contribution celebrated), but also tend to happen chronologically in that order…hence the premise of it being a ramp.
Just having knowledge of these four steps in the contributor process is useful in itself to be able to identify the kind of processes you need to put in place to serve the collaborative experience well. I want to build on these steps and take a quick spin through each of them to give you some examples of the processes I have put in place in the communities I have worked with.
It doesn’t matter how great your processes are farther up the on-ramp; if people don’t know they can take part in your community, they will never get involved.
Although this sounds obvious, it is easy to forget this important first component of the on-ramp when we are so busy and knee-deep in building processes, tracking their effectiveness, and dealing with problems and other work.
Part of the challenge here are the different levels of abstraction in your community. As an example, in the Ubuntu community we have many different teams: documentation writers, translators, packagers, bug triagers, and more. At a team level we have generally had the bases covered here; each team would have a website which made it clear that everyone is welcome to participate in her respective team. We went to great lengths to ensure that all the major teams had these pages in place and that new folks who would express an interest in a team would know their participation is desired and encouraged.
While this served us well at the team level, it was also important for us to do this at the higher general community level for people who were literally brand-new to Ubuntu and had no idea how the community works. In these cases people had typically tried Ubuntu and were curious about it, and we needed to inform them about how Ubuntu is a collaborative community and anyone can participate. This work was best done by highlighting the many different types of contributions and how these contributions typically map to teams, which then connects the prospective contributor to the team’s on-ramping process.
To do this we created a web page that highlighted these different types of contributions and then handed people off to different teams where a team member could continue the on-ramping of that person. We found this worked pretty effectively, but the high-level web page needed a lot of user testing, feedback, and changes to serve these needs well. We discovered that in creating this page we naturally presumed some knowledge that prospective members actually didn’t have; the user testing helped us to weed out these presumptions and bring more clarity.
We performed this user testing by putting together a page and asking a range of different types of users with different levels of experience to provide feedback on the page. We then reviewed the feedback, applied some changes to the page, and went through another round of user testing. This was hugely valuable in identifying the assumptions and errors in the page.
Skills acquisition is a critical piece in encouraging successful participation in community. If we want people to contribute to our community, they need to have the appropriate skills to be able to deliver good work.
Skills acquisition involves two broad challenges:
How do we provide all the facilities required to help new community members learn what they need to contribute?
How do we help give them the confidence to participate?
The former is the big, obvious challenge. Fortunately in the current age of the (mostly) ubiquitous Internet, self-learning is common. Most Internet users have used various websites and facilities and learned how to do something, be it using web email, using a piece of technology, or something else. The Internet is awash with varying quality levels of help and guidance for almost anything, and people around the world are used to performing research and self-teaching. As such, we want to try to produce processes and resources for learning these skills in our communities.
It is important to remember, though, that skills acquisition is not just about producing tutorials and documentation and putting them online. While this documentation does help, the pure availability of it does not necessarily mean people will read it. Also, when people read it they will likely have questions, problems and issues with their learning, and other areas in which they need help and guidance. As such, when building your solution here you want to strive to produce (a) core knowledge transfer material (e.g., documentation), (b) methods of encouraging the consumption of that material, and (c) support facilities to provide help and guidance.
In the Ubuntu community we served these kinds of needs in a few different ways. First we encouraged the community to document help and guidance that could be useful to others. This included the creation of a knowledge base of content and an actively communicated ethos that the knowledge base should be added to and extended when someone noticed that a key piece of information or guidance was missing. This would result in a growing resource of help and guidance.
We augmented this work with a set of Ubuntu training weeks. These events would produce a week-long set of tutorial sessions, many of which referenced this preexisting documentation, but these sessions also actively focused on teaching a particular skill or approach in the community (e.g., how to create documentation, how to fix a bug, etc.).
Finally, we provided a number of resources for getting help and guidance. This includes a web-based question and answer service, real-time IRC discussion channels, mailing lists, and more. This collection of resources would help provide all the necessary steps for prospective community members to up-skill themselves to contribute effectively.
In our two broad challenges earlier, I also highlighted the challenge of how do we help give them the confidence to participate?
This challenge is less about providing documentation resources and more about giving people the motivational support and encouragement that they really can learn the skills and contribute great things to the community. In many cases new prospective community members feel a little nervous and self-conscious about whether they can contribute, often because they see so many other smart and active contributors and feel unsure about whether they can match their abilities.
You should make a point of breaking down this self-doubt and replacing it with confidence and support from the community to help grow confidence in contributing. Achieving this usually involves plenty of positive messaging, positive reenforcement, and one-on-one encouragement.
While in most communities the previous two steps on the on-ramp get plenty of focus, the determining contributions component often gets less attention.
Part of the reason for this is that making people aware of the on-ramp and helping people to up-skill themselves is often a largely single-shot chunk of work that, when completed, we can forget about. The challenge of giving people something to work on requires more attention to detail as the tasks that need to be completed at any given time change from day to day.
The other challenge here is that different community members with different levels of experience are better suited to different types of work. As an example, an experienced programmer can dig into a code base and get started right away. On the other hand, someone who is very new to a project and programming language will need something much simpler to get started with. Now fold into the mix the many different types of contributions in a community (e.g., advocacy, documentation, translations) and it can be difficult to segment available tasks in ways that are best suited for different community members with different skills and competence levels.
The simple reality here is that for anything other than a small community, you won’t have the time to have an overview of all open tasks to be completed and ensure that they are assigned to people with a suitable expertise and skill level. What we instead need to focus our efforts on is ensuring that new starters can find something to do, and importantly, that they can feel a sense of accomplishment.
The sense of accomplishment of contributing something of value to the community is the secret recipe for success here. If a new community member can join a community, and have a small task to do that is performed and then accepted by the community, it provides a real sense of euphoria. We want to provide opportunities for these new members who can go from zero to hero and do something that is valued by the community.
Some years ago I trialled an approach in the Ubuntu community that has served us well in this regard. The idea was simple: identify a set of bug reports that don’t require extensive knowledge to fix and can be fixed within an hour, and put these bug reports in a bite-size category. We would then offer these bite-size bug reports to new members of the community who would be able to fix them within their skill level and thus feel a strong sense of accomplishment when they got accepted shortly afterward. This sense of accomplishment would fuel an energy and enthusiasm to fix another bug report, and build a sturdiness to learning more complex skills and contributing to more complex tasks.
To help disseminate these bite-size bugs I asked each member of my team to write weekly blog posts highlighting bugs that need to be resolved, and inviting prospective community members to take a look at these bugs. In each of these blog entries there would also be links to our up-skilling resources, support channels, and more. As such, these blog entries would provide a set of simple issues that need fixing, thank people who fixed the issues from the previous week (which grows the kudos part of the on-ramp), and also highlight a standard set of resources that can be used to learn the skills to fix those issues. We found these weekly posts to be successful in driving more participation in different teams.
When you get to this final component on the on-ramp, your community members have already committed extensively to your community; they have been inspired to participate, learned the skills they need, and contributed to a task that needed completing. In any typical case of one human being helping another with something, we say thanks; you should find ways to do the same thing in your community.
In small communities this is less of a problem: it is easy to see a contribution and thank the person who performed it. In bigger communities this can be more challenging; when there are hundreds or thousands of things going on every week or month it is impractical to be able to say thanks for everything. This is an important challenge to scale, though; validation is a key piece in helping to maintain a sense of belonging and appreciation for your community members.
I have traditionally focused on encouraging an appreciation culture in two core forms:
- Broadcast appreciation
Broadcasting out to the wider community appreciation for work and accomplishments made by particular teams or people
- Contextual appreciation
Saying thanks for work and accomplishments to the people who did them at a one-to-one level
Both of these approaches are important within collaborative communities. From the perspective of the community member being thanked, the broadcast approach is nice to see as you feel a sense of appreciation disseminated across the wider community; the wider community see that you did a great job. The contextual approach is nice to see to provide a general sense of appreciation in your day-to-day activities; you do something and someone says thanks and it makes the community feel positive and fun.
For the broadcast appreciation approach you should encourage your community to write blog entries and articles that highlight great work and thank people. This is particularly important for community leaders to do. Communities are social groupings and inspirational leaders thanking and highlighting great work is incredibly motivating.
In Ubuntu we have tackled this approach by encouraging a culture of thankful blogging and I have worked with our community leaders to encourage them to do this. In many cases this would involve me reaching out to a leader and asking this person to blog. In most cases the leader was happy to do this and the recipient of the kudos felt great when seeing it.
For the contextual appreciation approach this is more of a cultural norm that you want to build; you want to grow a culture in which it is normal to say thanks when someone does something for or contributes to the community. In Ubuntu we have approached this by regularly reminding people of and encouraging this behavior and highlighting the positivity it generates. We tend to repeat this message at every Ubuntu Developer Summit to keep it fresh.
Processes are living, breathing organisms. They are typically based on 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 practices 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 he has 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 not only has benefited prospective members, but also has meant that Community Council meetings have been more focused on governance issues than 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 a 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 10.
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 the session as a “governance and process review,” but rather as “how to improve our community.” Make sure your announcement welcomes everyone, and ensure that 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 on 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:
Make a list of all 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, and so on. I recommend you do this in an online document, such as a wiki page.
For each process, include bullet points outlining the feedback you have heard, both good and bad.
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.
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 submit feedback for you to add to the list. You should ask for feedback about the processes and 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 on the 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.
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, Second Edition 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.
