Our project gladly welcomes external contributions! We use Pull Requests.
A good way to familiarize yourself with the codebase and contribution process is to review the documentation. You can also look at our issue tracker. Before embarking on a more ambitious contribution, please get in touch with us.
If you would like to implement a new feature, please raise an issue before sending a pull request so the feature can be discussed. This is to avoid you wasting your valuable time working on a feature that the project developers are not interested in accepting into the code base.
If you would like to fix a bug, please raise an issue before sending a pull request, so it can be tracked.
A pull request requires approval from at least one of the maintainers.
We have tried to make it as easy as possible to make contributions. This applies to how we handle the legal aspects of contribution. We use the Developer's Certificate of Origin 1.1 (DCO) - which is the same that the Linux® Kernel community uses to manage code contributions.
When submitting a patch for review, we require that you include a sign-off statement in the commit message.
Here is an example Signed-off-by line, which indicates that the submitter accepts the DCO:
Signed-off-by: Jane Doe <jane.doe@example.com>
You can include this automatically when you commit a change to your local git repository using the following command:
git commit -s
To connect with us, please open an issue or contact one of the maintainers via email. See the MAINTAINERS.md page.
To ensure a working build, please run the full build from the root of the project before submitting your pull request. Pull Requests should include necessary updates to unit tests within the tests package.
Markdown is preferred for tables in the documentation. HTML can be used for complex table needs.