One of the easiest ways to contribute is to participate in discussions on GitHub issues. You can also contribute by submitting pull requests with code changes.
Start a discussion
Before reporting a new issue, try to find an existing issue if one already exists. If it already exists, upvote (👍) it.
Also, consider adding a comment with your unique scenarios and requirements related to that issue.
Upvotes and clear details on the issue's impact help us prioritize the most important issues to be worked on sooner rather than later.
If you can't find one, that's okay, we'd rather get a duplicate report than none.
Create a new bug or feature request in the repository issue tracker.
We are always happy to see PRs from community members both for bug fixes as well as new features. To help you be successful we've put together a few simple rules to follow when you prepare to contribute to our codebase:
You can find issues where we are looking for help by looking for the up-for-grabs label.
It is very likely that we will accept PR contributions for issues with this label.
Please do not start a PR without discuss the problem beforehand in an issue. Your PR will most likely get rejected if there was no issue created and discussion around the problem beforehand.
We've seen PRs, where customers would solve an issue in a way, which either wouldn't fit into the framework because of how it's designed or it would change the framework in a way, which is not something we'd like to do. To avoid these situations and potentially save you a lot of time, please discuss the design with us first!
To do so, create a new or comment on a feature request issue, and provide detailed information about how you'd like to solve a specific problem.
When you get an agreement from us that the design proposal you have is solid, then go ahead and prepare the PR.
Before submitting a pull request, make sure that it checks the following requirements:
- You find an existing issue, discuss with us to agree on accepting a PR
- You post a high-level description of how it will be implemented and receive a positive acknowledgement from the team before getting too committed to the approach or investing too much effort in implementing it.
- You add test coverage following existing patterns within the codebase
- Your code matches the existing syntax conventions within the codebase
- Your PR is small, focused, and avoids making unrelated changes
If your pull request contains any of the below, it's less likely to be merged.
- Changes that break backward compatibility
- Changes that add entirely new feature areas without prior agreement
- Changes that are mostly about refactoring existing code or code style
- Very large PRs that would take hours to review without prior agreement
A core contributor will review your pull request and provide feedback.
If you don't know what a pull request is read this article: https://help.github.com/articles/using-pull-requests. Make sure the repository can build and all tests pass. Familiarize yourself with the project workflow and our coding conventions.
Tests need to be provided for every bug/feature that is completed.
Your pull request will now go through extensive checks by the subject matter experts on our team. Please be patient. Update your pull request according to feedback until it is approved.
When your pull request has had all feedback addressed, it has been signed off by one or more reviewers with commit access, and all checks are green, we will commit it. We commit pull requests as a single Squash commit unless there are special circumstances. This creates a simpler history than a Merge or Rebase commit.