{"id":2319,"date":"2015-07-09T13:16:45","date_gmt":"2015-07-09T20:16:45","guid":{"rendered":"http:\/\/mozscienceblog.wpengine.com\/?p=2319"},"modified":"2019-02-28T12:40:09","modified_gmt":"2019-02-28T20:40:09","slug":"seven-steps-to-building-community-around-your-open-source-project","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/foundation-archive\/mozilla-science\/seven-steps-to-building-community-around-your-open-source-project\/","title":{"rendered":"Seven steps to building community around your open source project"},"content":{"rendered":"

Since the Mozilla Science Lab launched two years ago, we\u2019ve tested ways to help the research community work together to build new tools for science. Through our Collaborate platform<\/a> and code sprints<\/a>, we\u2019ve 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.<\/p>\n

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!<\/p>\n

Since Collaborate<\/a> is build around GitHub<\/a>, 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<\/strong>:<\/p>\n

<\/span><\/a>1. GitHub – public repository<\/h2>\n

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<\/a>, we require projects to be hosted on GitHub<\/a> (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.<\/p>\n

<\/span><\/a>2. LICENSE – open source<\/h2>\n

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

<\/span><\/a>3. README.md – make your mission clear<\/h2>\n

The text you place in README.md is often a user\u2019s first introduction to a project. Make sure you create a welcoming README that gives an overview of your project.<\/p>\n

Leading with a clear and concise mission statement will help the community understand what you\u2019re building. Keeping it short and simple will help others quickly understand and decide if they want to be a part of this project.<\/p>\n

<\/span><\/a>4. Public issue tracker<\/h2>\n

Tease out tasks in your issue tracker to help others understand where they can get involved and what\u2019s 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.<\/p>\n

Good first bugs<\/strong><\/p>\n

Good first bugs are an easy to implement onboarding process. Mark a few easier tasks as a \u2018good first bug\u2019 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.<\/p>\n

Characteristics of a good first bug<\/a>:<\/p>\n