| //Licensed under the Apache License, Version 2.0 (the "License"); |
| //you may not use this file except in compliance with the License. |
| //You may obtain a copy of the License at |
| // |
| //http://www.apache.org/licenses/LICENSE-2.0 |
| // |
| //Unless required by applicable law or agreed to in writing, software |
| //distributed under the License is distributed on an "AS IS" BASIS, |
| //WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| //See the License for the specific language governing permissions and |
| //limitations under the License. |
| = Guide to Successful Community Building |
| Apache Incubator PMC |
| 2002-10-16 |
| :jbake-type: guide |
| :jbake-status: published |
| :idprefix: |
| :toc: |
| :imagesdir: ../images/ |
| |
| Help to improve the system by posting a patch for |
| this document to the incubator section of JIRA or a |
| comment to the link:lists.html[general] list at |
| incubator. |
| |
| == Abstract |
| |
| The intent of this document is to help podlings the |
| importance of building an open and diverse community for |
| their project. It gives guidelines on how to accept new |
| committers and PPMC members, and how to enable more |
| community involvement, taking off the burden of answering |
| every question yourself. |
| |
| == What is an open and diverse community? |
| |
| A major criterion for graduation is to have developed an open |
| and diverse link:http://www.apache.org/foundation/glossary.html#Meritocracy[meritocratic] |
| community. Time has demonstrated that these kinds of |
| communities are more robust and productive than more closed |
| ones. |
| |
| === People |
| |
| 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 of the project. So, |
| this process is very beneficial. link:#notes-community[Community building] requires energy |
| which could have been spent on code development but this cost |
| is an important 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. Ways to resolve technical conflict |
| without destroying personal relationships must be learned. |
| |
| === Communication |
| |
| |
| Mailing lists are the life blood of Apache communities. They |
| are the primary mode of discourse and constitute a public and |
| historic record of the project. Other forms of communication |
| (P2P, F2F, personal emails and so on) are secondary. There are |
| well founded fears about use of these media for project |
| communication. Though many projects successfully blend other |
| forms of communications, care needs to be taken since |
| out-of-band communications have led to difficulties in the |
| past. The reason is that communications on other than the |
| public mail aliases exclude parts of the community. Even |
| publicly advertised IRC chats can be exclusionary due to time |
| zone constraints or conflicting time commitments by community |
| members who might want to participate. |
| |
| Apache project mailing lists are public, well indexed and well |
| archived. This allows anyone to monitor (both in real time and |
| by browsing the archives) what's happening. Opinions expressed |
| are public and poor behavior risks a poster's reputation. |
| |
| Private communications tend to be more candid but also more |
| likely to be ill-judged. Back channel communication tend to be |
| divisive, excluding some members of the group. This tends to |
| have a corrosive effect on the collective spirit of the |
| community. Mistrust builds when opinions backed by blocks of |
| developers arise fully formed on list. |
| |
| Communication through other channels also reduces the chance |
| of link:http://en.wikipedia.org/wiki/Serendipity[serendipity]. |
| As with most social networks, most subscribers to a mailing |
| 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 this topic arises on list. |
| Using public mailing lists to develop designs allows the |
| chance encounter of ideas which often results in innovation. |
| |
| If alternative forums are used by a project, it is important |
| to try to minimize the chances of problems arising. All |
| matters of substance need to be moved back to the mailing |
| lists. Public records should be kept and posted back to the |
| list. Regular reminders should be posted to remind people that |
| other secondary forms of communication exist. |
| |
| There are a limited number of topics such as security issues |
| and discussions about people which are best handled in |
| private. As much business of the project as possible should |
| take place on public lists but the private list is available |
| for those matters of a sensitive nature. Good netiquette |
| requires that permission from the poster should be sought |
| 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 mailing lists effectively is very important. |
| If this can be achieved, then you have shown to be a lively, |
| active and successful community. The future looks bright. |
| |
| === Community Building |
| |
| 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. In order to overcome this |
| obstacle, committers may need to devote more time to community |
| building and less to development. |
| |
| The link:mailto:community@apache.org[community mailing list] is open to all Apache committers. This is the right |
| list for questions about community and on community building. |
| Subscriptions should be from an Apache email address. |
| |
| ==== Raising The Profile |
| |
| Sometimes, a podling is just not well-enough known. There |
| are simply not enough users to allow new developers to be |
| recruited. Overcoming this means finding ways to raise the |
| profile of the podling. Some ideas: |
| |
| - Improve the website |
| - Improve the information provided within each release and release more often |
| - Committers who blog should join link:http://www.apache.org/dev/committers.html#planetapache[PlanetApache] |
| - Use grassroots media |
| - Encourage downstream distributions to include a packaged version |
| - Submit talks to conferences |
| - link:http://www.feathercast.org[Feathercast] |
| - Write articles |
| |
| ==== Building a community by stepping back a little |
| |
| |
| If the podling has lots of users but very few new |
| developers then this means that more work is required 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 become more involved at the |
| expense of user satisfaction. |
| |
| 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 isn't covered in the |
| documentation, ask them to submit a patch. When users |
| suggest a good design or extension, ask for volunteers to |
| help implement rather than just coding it up. |
| |
| ==== Helping Developers Become Committers |
| |
| If a podling has no trouble attracting developers but |
| trouble retaining them long enough for them to become |
| committers then 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. |
| |
| Promptly reviewing patches is important. The way that |
| patches are applied is also important. Provide credit in |
| the commit message and when closing the JIRA. It's also |
| good to encourage developers by suggesting new related |
| work they may like to volunteer for. |