Seven steps to building community around your open source project

Mozilla

Since the Mozilla Science Lab launched two years ago, we’ve tested ways to help the research community work together to build new tools for science. Through our Collaborate platform and code sprints, we’ve seen that collaborative learning and building happens when a community forms around a project. We want to invest in leaders who can help the research community learn to build software together.

By working openly, a project lead demonstrates and encourages learning and participation. While mentorship and community engagement are vital throughout the life of a project, a few key steps can help jumpstart community involvement. This post outlines a few choices that will help you work in the open and reduce barriers for new contributors!

Since Collaborate is build around GitHub, these steps are a bit GitHub centric, but many open source projects have a thriving community using others public repositories. Here are seven steps to building community around your open source project:

1. GitHub – public repository

Put your work in a public repository! This allows others to see your work in progress and follow each change you make real time. On Collaborate, we require projects to be hosted on GitHub (as a best practice and to help with our integration). GitHub enables distributed collaboration and has a built-in public discussion forum in their issue tracker.

2. LICENSE – open source

Make sure your project is actually open source and allows for public contributions. Choose an open source license (we recommend MIT or BSD). Take a look at choosealicense.com for more details.

3. README.md – make your mission clear

The text you place in README.md is often a user’s first introduction to a project. Make sure you create a welcoming README that gives an overview of your project.

Leading with a clear and concise mission statement will help the community understand what you’re building. Keeping it short and simple will help others quickly understand and decide if they want to be a part of this project.

4. Public issue tracker

Tease out tasks in your issue tracker to help others understand where they can get involved and what’s being worked on. Issues communicate specific needs or questions to contributors. Take time to document tasks, features, bugs, or questions in the issue tracker to let others know how they can help. This is often the main forum for public discussion on a project.

Good first bugs

Good first bugs are an easy to implement onboarding process. Mark a few easier tasks as a ‘good first bug’ to encourage newcomers. This will help new users easily walk through the contribution process and experience setting up their development environment, going through review and communicating with the project community.

Characteristics of a good first bug:

  • narrowly scoped
  • links to code that needs to be changed
  • has someone signed up as a mentor
  • not time-critical or blocking

5. CONTRIBUTING.md – contributor guidelines

Jumping into a new project can be hard and intimidating. Lower the friction to join in by having contributor guidelines (usually in a CONTRIBUTING.md file, linked from the README). This document will help others understand the way your community works and how you interact with each other.

Good questions to address in contributor guidelines:

  • How do I report a bug?
  • How do I set up my development environment?
  • How do I submit changes to the code base?
  • Where can I ask for help? – make sure you point users to an IRC channel / forum / email address that will be responsive and welcoming to newcomers.

6. Roadmap – development status

Once your community decides what to work on, write it down! Creating a roadmap helps others understand the current status of your project and where it’s going next. A roadmap can also express your vision for the project. Make sure you clearly state why you are implementing certain things to get people excited about joining.

This can be as simple as a collection of issues in your issue tracker, or a detailed timeline complete with milestones. It’s up to you to choose what works best for your community!

7. Mentorship – engage your community

This final step is ongoing is probably deserves a post of it’s own. Investing time to help a few volunteers will build your community and raise new leaders within your project. This can be as simple as responding cheerfully to issues, mentoring bugs or hosting a project call with your contributors. Let others know you appreciate their hard work and help them be better leaders!

We’re still testing out ways to help project leads build a community around their contributors. We hope these seven steps are a good start! Are we missing anything? Do these help at all? Let us know what you think in the comments!

Help us foster collaborative learning while building projects that help researchers leverage the open web.

What’s next: