This document is to help each podling understand the importance of building an open and diverse community for its project. It gives guidelines on how to accept new committers and PPMC members and how to enable more community involvement.
What is an open and diverse community?
A major criterion for podling graduation to Top Level Project (TLP) status is to have developed an open and diverse meritocratic community. These kinds of communities are more robust and productive than more closed ones are.
As a project grows, it needs to renew itself by accepting new committers. A project needs to learn how it can recruit new developers and committers into the community. Accepting new committers usually increases the diversity and strength of the project. Community building requires energy which could have been spent on code development, but this cost is an essential investment for the future of the project.
The openness of the community is not only measured by the number of contributors. Open and respectful discussions on the mailing lists are vital. Community members must learn ways to resolve technical conflicts without destroying personal relationships.
Email lists are the lifeblood of Apache communities. They are the primary mode of discourse and constitute a public and historical record of the project. Other forms of communication (P2P, F2F, personal emails, instant messaging platform posts, and so on) are secondary. There are well-founded fears about the use of other forms of project communication. Though some projects successfully blend other forms of communications, projects need to take care since out-of-band communications have led to difficulties in the past. The reason is that conversations on other than the public email list exclude parts of the community. Public instant message communication can be exclusionary due to time zone constraints or conflicting time commitments by community members who would want to participate.
Apache project email lists are public, archived and searchable. This allows anyone to monitor (both in real-time and by browsing the archives) what’s happening. Opinions expressed are in the open and poor behavior risks a poster’s reputation.
Private communications tend to be more candid but also more likely to be ill-judged. Backchannel communication tends to be divisive, excluding some members of the group. This tends to have a corrosive effect on the collective spirit of the community. Trust erodes when opinions backed by blocks of developers appear from nowhere, fully formed, on the email list.
Communication through other channels also reduces the chance of serendipity. As with most social networks, most subscribers to a email list never post and most posts come from a tiny minority of subscribers. Some passive subscribers are just interested in where the project is going. But others understand related fields and have a limited intersection of interest. This second group will often post when a topic in which they are interested arises on a list. Using public email lists to develop designs allows the chance encounter of ideas which often results in innovation.
If a project uses alternative forms of communication, it is essential to try to minimize the chances of problems arising. All matters of substance need to move back to the email lists. Projects need to preserve, and post back to the lists, significatn conversation threads in other channels. Project should post regular reminders that other secondary forms of communication exist.
There is a limited number of topics, such as security issues and discussions about people, which it is best to handl in private. As much business of the project as possible should take place on public lists, but the private list is available for matters of a sensitive nature. Good netiquette requires that you seek permission from the poster before making public posts made to a private list. Try to avoid cross-posting between public and private forums. Take care not to post a reply to a private post to a public forum without permission.
Learning to use email lists effectively is very important. If your project community can achieve this, it has a good chance to be lively, active and thriving. The future looks bright.
Before a podling graduates, it must create a diverse and self-sustaining community. Community-building is tough: it takes time, effort and more than a little magic. There is no secret recipe, just hard work. To address this challenge, committers may need to devote more time to community-building and less to development.
The community email list is open to all Apache committers. This is the right list for questions about the Apache community and on community-building. Subscribe using your Apache email address.
Raising The Profile
Sometimes a podling is just not well-enough known. There are not enough users to recruit new developers from. Overcoming this means finding ways to raise the profile of the podling. Some ideas:
Improve the website
Improve the information you provide within each release
Release more often
Simplify the build process
Improve project documentation
Provide getting-started examples and tutorials
Use grassroots media
Encourage downstream distributions to include a packaged version
Submit talks to conferences
Write blogs and articles
Building a community by stepping back a little
If the podling’s software has lots of users but very few new developers, the community needs to do more work to encourage users to become developers. A common cause of this is that committers are too quick to create code to solve user problems. It’s good to respond quickly to requests by users. However, once a project gains momentum, it may be more productive for the long-term health of a project to encourage users to propose solutions to non-critical problems and, thus, become more involved.
Try to encourage expert users to answer questions. This may mean intentionally allowing a time gap before answering user questions. Encourage users to post by taking the time to deal politely and positively with misunderstandings and by replying to threads which have been answered well by a user to confirm that they are right. Avoid engaging in flame wars on user lists. Ignore trolls.
Try to encourage users to become developers. When they give a good answer that the documentation doesn’t cover, ask them to submit a patch. When users suggest a good design or extension, ask for volunteers to help implement it rather than just coding it up.
Helping Developers Become Committers
If a podling has no trouble attracting developers but difficulty retaining them long enough for them to become committers, this highlights an issue with the recruitment process. To become an Apache committer, a developer needs to hang around long enough to accumulate a track record of contributions. This often requires encouragement and help from existing committers. It may also be that the committer bar is set too high.
Promptly reviewing patches or pull requests is essential. The way the project applies patches is also important. Provide credit in the commit message and when closing the issue. It’s also good to encourage developers by suggesting new related work they may like to volunteer to work on.