From e2d7920bb3ffd8e9aad470b217f2a29d7cc0e1c1 Mon Sep 17 00:00:00 2001 From: Nicola Demo Date: Mon, 17 Jul 2023 18:52:35 +0200 Subject: [PATCH] Create CONTRIBUTING.md --- CONTRIBUTING.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 00000000..84ad81db --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,40 @@ +## How to contribute +We'd love to accept your patches and contributions to this project. There are just a few small guidelines you need to follow. + +### Submitting a patch + + 1. It's generally best to start by opening a new issue describing the bug or + feature you're intending to fix. Even if you think it's relatively minor, + it's helpful to know what people are working on. Mention in the initial + issue that you are planning to work on that bug or feature so that it can + be assigned to you. + + 2. Follow the normal process of [forking][] the project, and setup a new + branch to work in. It's important that each group of changes be done in + separate branches in order to ensure that a pull request only includes the + commits related to that bug or feature. + + 3. To ensure properly formatted code, please make sure to use 4 + spaces to indent the code. The easy way is to run on your bash the provided + script: ./code_formatter.sh. You should also run [pylint][] over your code. + It's not strictly necessary that your code be completely "lint-free", + but this will help you find common style issues. + + 4. Any significant changes should almost always be accompanied by tests. The + project already has good test coverage, so look at some of the existing + tests if you're unsure how to go about it. We're using [coveralls][] that + is an invaluable tools for seeing which parts of your code aren't being + exercised by your tests. + + 5. Do your best to have [well-formed commit messages][] for each change. + This provides consistency throughout the project, and ensures that commit + messages are able to be formatted properly by various git tools. + + 6. Finally, push the commits to your fork and submit a [pull request][]. Please, + remember to rebase properly in order to maintain a clean, linear git history. + +[forking]: https://help.github.com/articles/fork-a-repo +[pylint]: https://www.pylint.org/ +[coveralls]: https://coveralls.io +[well-formed commit messages]: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html +[pull request]: https://help.github.com/articles/creating-a-pull-request