The Apache Software Foundation
Community > Code
Growing your project community takes work. This document makes practical suggestions of how to encourage people to get involved in your project.
Publish a roadmap ¶
Volunteers can work on whatever they want, and so we have a tendency to not want to tell them what to work on. However, publishing a roadmap, or even a wishlist of features or improvements that are desired, can give people an idea of where they might be able to get involved.
This also gives a clear sense that the project has ambitions, and is going somewhere, rather than that it is stagnating.
It can be very challenging to keep a roadmap current. Having a mechanism
for tagging open issues with proposal or roadmap and
automatically extracting that into a web page can help with this.
Periodically publish the open issue list ¶
Your ticket tracker allows you to periodically summarize the open issues. Sending this to the dev@ list reminds people that there are things to work on, and gives them permission, and encouragement, to do so.
Consider creating good first issues as a place for new contributors to get started.
Clearly document contribution processes ¶
Double-check that your “how to contribute / build / test / submit PR” documentation is super clear and easy to follow. Long-time committers on a project often forget all the institutional knowledge they just “know”, so ensuring the “getting started” document actually works for newcomers is always worth looking at.
Encourage newcomers to talk about, and document, their pain points during their first contributions, and work towards fixing, or at least documenting, those things.
Publish your contributor ladder ¶
A contributor ladder is a description of various levels of access and responsibility a contributor can progress through in your project. This is typically the path from contributor, to committer, to PMC member.
Explicitly publish your requirements for each step. For example, if you require ten non-trivial patches accepted, or perhaps 3 months of involvement, document this on your website so that people don’t feel that it’s random, or that they are driving in the dark.
Consider lowering your bar to entry. Remember that while the risk of inviting someone “too early” is that they’ll break something, that’s why you have version control - so you can revert those changes. However, the risk of inviting someone too late is that they’ll give up and go away forever.
Engage with big users ¶
If you are aware of companies that rely on your project, encourage them to think about what they would do if the project retired. This often leads to those companies realizing the value they get “for free”, and starting to contribute in some way.
Be transparent about project risk ¶
If your project is actually at risk of retiring due to lack of community engagement, be transparent about this. Tell your dev and user lists about the risk, and tell them specifically where you need help.
While many users are content to simply consume, when they become aware that the project is at risk, it often inspires people to think about ways they can get involved.
Come talk to us ¶
You’re always welcome to come talk to the Community Development project, for advice and resources. We don’t always have all of the answers, but we can help you think about the problem, and suggest possible solutions.
Engage with one of our working groups to help implement some of the above advise.