Ubuntu Wiki

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

Accessing Needs

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.

The Gates of Your Community

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.

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.

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.

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.

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.

One final note about feedback is related to expectations. You should prepare yourself to receive more criticism than praise. This is simply the nature of community and human interaction: we often feel compelled to write an email to criticize, but we rarely get an urge to send email to praise. As such, if you receive what appears to be a large amount of criticism, it may not be reflective of your community. It is likely that there are a lot of silent yet happy members out there.