Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Writing code that can be incorporated into the project itself
- Proposing new features
- Improving the documentation
- Writing tutorials or blog posts
- Becoming a maintainer
When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change.
As for everything else in the project, the contributions to [PROJECT/REPO] are governed by our Code of Conduct[REFERENCE].
First things first: Do NOT report security vulnerabilities in public issues! Please disclose responsibly by letting the (TEAM NAME/EWF team) (EMAIL/[email protected]) know upfront. We will assess the issue as soon as possible on a best-effort basis and will give you an estimate for when we have a fix and release available for an eventual public disclosure.
The issue tracker is the preferred channel for bug reports, features requests and submitting pull requests, but please respect the following restrictions:
-
Please do not use the issue tracker for personal support requests. Use our [Slack channel/whatever].
-
Please do not derail or troll issues. Keep the discussion on topic and respect the opinions of others.
Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.
At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first 😸
If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge.
- Fork the repo, clone it to your own machine and create your branch from
master
- Commit changes to your branch
- If you've added code that should be tested, add tests
- If you've changed APIs, or if needed, update the documentation, README, etc.
- Ensure the test suite passes.
- Make sure formatting is according to the repo`s style guidelines. Use a linter if needed.
- Push your work back to your fork
- Create that pull request
- Pass the review, reiterate if requests are made by the maintainers
NOTE: Be sure to merge the latest from "upstream" before making a pull request!
Don't forget to review your own code first. Does it make sense? Did you include something unrelated to the overall purpose of the changes? Did you forget to remove any debugging code?
Our code review process is based on the following guidelines:
Especially pay attention to the "Having your code reviewed" section.
All of your contributions will be made under GNU v3.
[Contributor's License Agreement if there is any]