Did you find a bug or want to contribute with a feature? Please, know how you can help and what tools are available to simplify your experience contributing to the project.
Do not open up a GitHub issue if the bug is a security vulnerability. Refer to our security policy instead. Before opening an issue, check if it wasn't reported before under Issues.
Provide evidence of the bug so the maintainers can reproduce the bug.
Before opening an issue, check if it wasn't suggested before under the Ideas discussion category or if a solution is in progress under Pull requests. Please, gather feedback and guidance from the maintainers. As the project is still in its v0 major version, its API and design principles still need to be documented.
Follow the same steps as contributing to a new feature or change request.
Please, before submitting your code, run the test suite:
./gradlew test
Only submit a PR after guaranteeing all tests passed. The test execution will generate the code coverage reports. You
can check the coverage by opening the file percentage/build/reports/jacoco/test/html/index.html
in a browser.
The code conventions are automatically checked by Detekt on each build. However, before submitting your code, run Detekt locally:
./gradlew detekt
Then fix any issue found by the tool. The GitHub Actions build fails when one or more violations are detected by Detekt.
The project uses the model defined by Tim Pope:
Capitalized, short (50 chars or less) summary
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages
generated by commands like git merge and git revert.
Further paragraphs come after blank lines.
* Bullet points are okay, too
* Typically a hyphen or asterisk is used for the bullet, followed by a
single space, with blank lines in between, but conventions vary here
* Use a hanging indent
Issue: link to the relevant issue
See: any relevant link related to the committed changes
The model is simple: a subject and an optional body (separated by a line break). The subject must be short and start with a verb in the imperative. The body may further explain the motivation for the change. See the existing commit messages for further examples.
If PRs are opened containing commit messages using different formats, the maintainers will ask for a commit message
rewrite. This can be done with the git rebase -i
command.
All commits must be signed. GitHub has documentation describing how to set up Git to sign your commits using GPG.