We welcome your contributions to this project.
It could be:
- a bug report in a GitHub issue
- a feature request in a GitHub issue
- a fix to documentation
- a code contribution to address an existing bug or feature request
- a code contribution to fix a bug that you found
- a code contribution to add a new feature
By contributing to this project, you license your contribution under the same license that we use.
Before opening a bug report, please search the existing GitHub issues to see if it has already been reported.
If you find an existing bug report, please give the original report a thumbs-up. This helps us to understand how many people are affected by it.
If you have additional information that can help us understand the behaviour of the bug, how it presents in your configuration, or its impact, please add that as a comment.
If no issue already exists for the bug, please create a new one.
When creating a bug report, please fill out the template. What really helps us are the steps for us to be able reproduce the problem in front of us.
To generate these, start from nothing, and document the steps required to set up a project that shows the bug. If you create such a project as a new GitHub repo, you will have a Minimal Reproducible Example. We can then check out that project and see the bug in front of us immediately. This will increase the speed that we can address the issue. It will also help you isolate the actual issue, and sometimes to fix it.
Before opening a feature request, please search the existing GitHub issues to see if it already exists.
If you find an existing feature request, please give the original report a thumbs-up. This helps us to understand how many people want it.
If you have additional information that can help us understand the behaviour you need, or another use case not covered in the existing comments, please add that as a comment.
If no issue already exists for the feature request, please create a new one.
When creating a feature request, please fill out the template. What really helps us are both the motivation for the feature (what is your use-case and what you want to achieve), as well as what you would like the feature to be. Sometimes there is an existing way to accomplish what you want, and we may be able to recommend that.
If there is no existing way to do it, then understanding the use-case that motivates the feature request helps us to triage it, and also to design the feature implementation.
Maybe while getting started, you notice a step or a dependency that we missed out, or something that would have helped you. In that case, opening a Pull Request with a patch that adds it will help others when they get started. They may never know to thank you for it, but we will!
Please read the Code Style Guidelines and Commit Message Guidelines to ensure that your code matches the coding style of the project. This makes it easier for us to merge your contribution.
Maybe you patch an existing bug, or implement a requested feature for yourself - without waiting for us to get to it. You can contribute that to the codebase as a pull request. This way, you don't end up maintaining a separate fork.
See the section Running a development version for instructions on how to use your fork locally to test your changes.
Please read the Code Style Guidelines and Commit Message Guidelines to ensure that your code matches the coding style of the project. This makes it easier for us to merge your contribution.
If you are implementing a feature, it is a good idea to comment on the issue with your proposed approach. Early feedback and coordination increases the chances that we can merge it.
Maybe you find a bug, dig into the source code, and patch it for yourself. See the section Running a development version for instructions on how to use your fork locally to test your changes.
See the section Running a development version for instructions on how to use your fork locally to test your changes.
Please read the Code Style Guidelines and Commit Message Guidelines to ensure that your code matches the coding style of the project. This makes it easier for us to merge your contribution.
When you have a working fork, create a Pull Request, and open a new GitHub issue that describes the issue that you've fixed. If you make the pull request title for your fix "Fixes #${GitHub Issue Number}", then the bug report will be automatically closed when we merge it.
Maybe you implement a missing feature that you want. That's the beauty of open source - we co-create it. To get that merged into the code base, open a feature request issue. It's a good idea to discuss your proposed approach with us in an feature request issue. We might be planning to do it already and have an idea, or maybe we can help you identify the best approach given our familiarity with the codebase.
See the section Running a development version for instructions on how to use your fork locally to test your changes.
Please read the Code Style Guidelines and Commit Message Guidelines to ensure that your code matches the coding style of the project. This makes it easier for us to merge your contribution.
When you have a working fork, create a Pull Request. If you make the pull request title for your fix "Fixes #${GitHub Issue Number}", then the feature request will be automatically closed when we merge it.
@TODO: Document the coding style guidelines here.
Ideally put a .editorconfig file or similar in the project to automate this, and tell people how to add a plugin to their IDE to utilise it.
@TODO: Document your commit message guidelines here.
Give specific concrete examples as well as the format. Many people find it easier to work backwards from examples than to work forward from rules.
@TODO: tell people how to use their fork of your project locally.
This project is licensed under @TODO: license.
Any contributions you make to this project will be licensed under this license.
This project adheres to the Contributor Covenant Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to code-of-conduct@zeebe.io.