Skip to content

Latest commit

 

History

History
89 lines (60 loc) · 3.53 KB

CONTRIBUTING.md

File metadata and controls

89 lines (60 loc) · 3.53 KB

Contribution guidelines

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.

Bug fix

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.

New feature or change request

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.

Contributing to the documentation

Follow the same steps as contributing to a new feature or change request.

Developing

Testing and code coverage

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.

Code conventions

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.

Commit message

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.

Sign-off your commits

All commits must be signed. GitHub has documentation describing how to set up Git to sign your commits using GPG.