Do you run an open-source project that aims to build a community of contributors? Here is a guide on how to create contributor-friendly projects.
Once you have a few people interested in contributing to your project, there are several different ways that you can stay connected and keep each other informed.
In case you missed part one of this article, click here to gain insights on attracting contributors to your project.
Open-source projects must have clear rules for how to talk to each other. Additionally, it is necessary that you onboard new contributors to these ways of communicating. If you want to have an active community of contributors to your open-source repo, it is helpful to make the repo as self-explanatory as possible. It will prevent any unnecessary communication problems or barriers to entry for newcomers. This article will provide a guide on how to create contributor-friendly projects.
Table of Contents
Simple steps to create a contributor-friendly project:
Here is a step-by-step guide to creating contributor-friendly projects for an active community of contributors to your open-source repo.
Step 1: Documentation
Proper documentation for your project is key to making it more friendly. Document the steps to set up the project, known issues, and a guide on properly contributing to the project with a CONTRIBUTING.md or by adding steps to your README.md.
Readme.MD basics
A good README document ensures that contributors can easily start your open-source project. Many solid README docs start with a short description of the project and, more importantly, the “why” behind the project. Give your future contributors a general idea of why they should contribute to your project.
Ensure your contributors know the quickest way to start contributing to your project.
- Are there any prerequisites to working on this project?
- What kind of skills or software do they need to contribute properly?
- What is the step-by-step process for properly setting up your project’s development environment?
Additionally, ensure that your contributors understand how to run system tests. Describe the tests, their significance, and proper administration.
To eliminate potential obstacles for contributors to work on your project, you must include an Open Source License in your README file. Open source licenses make it clear that contributors can use this, modify it, and distribute it without payment.
Most README files provide contributors with a summary of the contents of the license and a link to the license document.
Optional (but potentially helpful) additions to the README doc:
- Who is your core team, and what is their contact information?
- Easiest ways to get in contact with you & the best time of day
- General FYI’s such as ‘please ask before spending your valuable time on a pull request (PR.).’
Step 2: Welcome New Contributors
Always make sure you appreciate new contributions, whether they are a feature, a bug fix, or an issue report. Sometimes, these contributions can go unnoticed, and new contributors might feel discouraged and disappointed by the lack of response. Luckily, apps like the Welcome Github app can help you with that.
The welcome bot will post a message when they create a new issue, open a PR, or merge a PR for a new contributor. It is a nice way to make a person contributing to your project for the first time feel welcome.
Source: GitHub
Step 3: Code Reviews
You would want to review a Pull Request (PR) after submission. Be objective, but celebrate and encourage changes whenever possible. It will welcome the contributor’s changes and encourage them to keep working on the PR if you request changes.
Step 4: Communication
A direct communication channel with the users of your projects is an excellent way to make them feel welcome. Depending on the size of your project, you could create a Slack or IRC channel for contributors. People would then be able to ask open-ended questions directly regarding how to solve a simple problem or any doubts they may have.
Step 5: Label issues.
In modern issue trackers, you can label issues with a brief description to know what they are about before reading them. It allows a contributor to filter issues by their label and work on something that interests them.
These are some examples of suitable labels for new contributors:
- Easy
- Help Wanted
- Beginner
- first-timers-only
- Good First Issue
The other labelling aspect is the external ecosystem around GitHub issues. For example, sites like Up For Grabs allow anyone to search for issues labelled “help-wanted” across all public repositories on GitHub. Good First Issue lets you find issues labelled “good first issue” that is well suited for beginners. Applying such labels will connect you with others who otherwise wouldn’t know about your project in the first place.
Check the issue tracker of “offen/offen” to see how we label our issues here.
Conclusion
It may be challenging to maintain an open-source project. But if you create a contributor-friendly project by making it a pleasant and inviting space for others to contribute. In the long run, it may become easier to maintain.
