One of the most important resources that an open source project can provide to potential contributors is contributor guidelines. When eager new contributors rush over to your project to make their first open source contribution, they rely on your contributor guidelines to be their guiding hand. That means that contributor guidelines should be easy to read, thorough, and friendly.

You’ll find a template for contributor guidelines for a particular git workflow below. In case you are interested in developing your own, here are some tips and tricks:

1. The majority of people who are reading your contributor guidelines have never contributed to your project. As such, your guidelines should be targeted at new contributors.
2. Recognize the fact that the reader is about to make a contribution to an open source project, which is no small feat. Let the reader know that the maintainers, other contributors, and users of the project appreciate this effort. This can serve as motivation for the new contributor.
3. Make sure that your contributor guidelines are thorough. Don’t be afraid to repeat information that you might think is redundant. Yes, there are plenty of resources online that explain how to clone a repository or how to submit a pull request, but a new contributor might not be aware of this. Make sure that your contributor guidelines are the authoritative resource on how to interact with the project.
4. Keep a light and friendly tone in your contributor guidelines. Make a few jokes. Include a few puns. New contributors are nervous about contributing to a project, and a jovial tone in your contributing guidelines can help alleviate that.
5. Tagging and labeling issues might be a cumbersome process for maintainers, but it does wonders for new contributors and users of the project. Labels that denote the category a particular issue falls in (design, documentation, front-end, back-end, etc), the effort level associated with a particular issue, and the priority associated with a particular issue.

Contributor guidelines template

What do I need to know to help?

If you are looking to help to with a code contribution our project uses [insert list of programming languages, frameworks, or tools that your project uses]. If you don’t feel ready to make a code contribution yet, no problem! You can also check out the documentation issues [link to the docs label or tag on your issue tracker] or the design issues that we have [link to design label or tag on issue tracker if your project tracks design issues].

If you are interested in making a code contribution and would like to learn more about the technologies that we use, check out the list below.

• Include bulleted list of
• resources (tutorials, videos, books) that new contributors
• can use to learn what they need to know to contribute to your project

How do I make a contribution?

Never made an open source contribution before? Wondering how contributions work in the in our project? Here’s a quick rundown!

1. Find an issue that you are interested in addressing or a feature that you would like to add.
2. Fork the repository associated with the issue to your local GitHub organization. This means that you will have a copy of the repository under your-GitHub-username/repository-name.
3. Clone the repository to your local machine using git clone https://github.com/github-username/repository-name.git.
4. Create a new branch for your fix using git checkout -b branch-name-here.
5. Make the appropriate changes for the issue you are trying to address or the feature that you want to add.
6. Use git add insert-paths-of-changed-files-here to add the file contents of the changed files to the “snapshot” git uses to manage the state of the project, also known as the index.
7. Use git commit -m “Insert a short message of the changes made here” to store the contents of the index with a descriptive message.
8. Push the changes to the remote repository using git push origin branch-name-here.
9. Submit a pull request to the upstream repository.
10. Title the pull request with a short description of the changes made and the issue or bug number associated with your change. For example, you can title an issue like so “Added more log outputting to resolve #4352”.
11. In the description of the pull request, explain the changes that you made, any issues you think exist with the pull request you made, and any questions you have for the maintainer. It’s OK if your pull request is not perfect (no pull request is), the reviewer will be able to help you fix any problems and improve it!
12. Wait for the pull request to be reviewed by a maintainer.
13. Make changes to the pull request if the reviewing maintainer recommends them.
14. Celebrate your success after your pull request is merged!

Where can I go for help?

If you need help, you can ask questions on our mailing list, IRC chat, or [list any other communication platforms that your project uses].

What does the Code of Conduct mean for me?

Our Code of Conduct means that you are responsible for treating everyone on the project with respect and courtesy regardless of their identity. If you are the victim of any inappropriate behavior or comments as described in our Code of Conduct, we are here for you and will do the best to ensure that the abuser is reprimanded appropriately, per our code.