Great!! We are always on the lookout for more OpenEBS hackers. You can get started by reading this overview
Firstly, if you are unsure or afraid of anything, just ask or submit the issue or pull request anyways. You won't be yelled at for giving your best effort. The worst that can happen is that you'll be politely asked to change something. We appreciate any sort of contributions and don't want a wall of rules to get in the way of that.
However, for those individuals who want a bit more guidance on the best way to contribute to the project, read on. This document will cover all the points we're looking for in your contributions, raising your chances of quickly merging or addressing your contributions.
That said, OpenEBS is an innovation in Open Source. You are welcome to contribute in any way you can and all the help provided is very much appreciated.
There are a few simple guidelines that you need to follow before providing your hacks.
When raising issues, please specify the following:
- Setup details need to be filled as specified in the issue template clearly for the reviewer to check.
- A scenario where the issue occurred (with details on how to reproduce it).
- Errors and log messages that are displayed by the software.
- Any other details that might be useful.
Getting documentation right is hard! Refer to this page for more information on how you could improve the developer documentation by submitting pull requests with appropriate tags. Here's a list of tags that could be used for the same. Help us keep our documentation clean, easy to understand, and accessible.
There is always something more that is required, to make it easier to suit your use-cases. Feel free to join the discussion on new features or raise a PR with your proposed change.
- Join OpenEBS community on Kubernetes Slack - Already signed up? Head to our discussions at #openebs
Provide PRs with appropriate tags for bug fixes or enhancements to the source code. For a list of tags that could be used, see this.
- For contributing to K8s demo, please refer to this document.
- For checking out how OpenEBS works with K8s, refer to our documentation
- For contributing to Kubernetes OpenEBS Provisioner, please refer to this document.
Refer to this document for more information on code structuring and guidelines to follow on the same.
Head over to issues to find issues where help is needed from contributors. See our list of labels guide to help you find issues that you can solve faster.
A person looking to contribute can take up an issue by claiming it as a comment/assign their GitHub ID to it. In case there is no PR or update in progress for a week on the said issue, then the issue reopens for anyone to take up again. We need to consider high priority issues/regressions where response time must be a day or so.
We use the Developer Certificate of Origin (DCO) as an additional safeguard for the OpenEBS project. This is a well established and widely used mechanism to assure contributors have confirmed their right to license their contribution under the project's license. Please read developer-certificate-of-origin.
Please certify it by just adding a line to every git commit message. Any PR with Commits which does not have DCO Signoff will not be accepted:
Signed-off-by: Random J Developer <random@developer.example.org>
or use the command git commit -s -m "commit message comes here" to sign-off on your commits.
Use your real name (sorry, no pseudonyms or anonymous contributions). If you set your user.name and user.email git configs, you can sign your commit automatically with git commit -s. You can also use git aliases like git config --global alias.ci 'commit -s'. Now you can commit with git ci and the commit will be signed.
Want to actively develop and contribute to the OpenEBS community, refer to this document.