The code alone doesn’t cause this to happen. As in the proverb, “it takes a village to raise a child,” it takes a community to create a healthy open source project. All participants in an open-source ecosystem have the opportunity to shape and improve the software. Users can identify features they need, and contribute code upstream. Everyone has a chance to make a difference.
We at SEF now have a significant amount of contributors in our community. We can do more great things by expanding it. Today, the challenge is to share one essential thing we can do to expand our community.
I’ll start with a simple one.
Make people feel welcome
One way to think about your project’s community is through what Mike Mc Quaid calls the contributor funnel:
As we build our community, we need to consider how someone at the top of the funnel (a potential user) might theoretically make their way to the bottom (an active maintainer). Our goal is to reduce friction at each stage of the contributor experience. When people have easy wins, they will feel incentivized to do more.
Start with documentation:
- Make it easy for someone to use our project. A friendly README and clear code examples will make it easier for anyone who lands on our project to get started.
- Clearly explain how to contribute, using your CONTRIBUTING file and keeping the issues up-to-date.
- Good first issues: To help new contributors get started, we need to consider explicitly labeling issues that are simple enough for beginners to tackle. GitHub will then surface these issues in various places on the platform, increasing useful contributions, and reducing friction from users tackling issues that are too hard for their level.
We can use these interactions as opportunities to move them down the funnel.
- When someone new lands on our project, thank them for their interest! It only takes one negative experience to make someone not want to come back.
- Be responsive. If we don’t respond to their issue for a month, chances are, they’ve already forgotten about your project.
- Be open-minded about the types of contributions you’ll accept. Many contributors start with a bug report or a small fix. There are many ways to contribute to a project. We should let people help how they want to help.
- If there’s a contribution we disagree with, we should thank them for their idea and explain why it doesn’t fit into the scope of the project, linking to relevant documentation if we have it.
I nominate @akshika47