2 KiB
2 KiB
| id | title |
|---|---|
| contributing | Contributing |
Compiling project
- It's recommended to use Java 11.
- Build with
sbt, to install sbt see https://www.scala-sbt.org/ - Use
sbt tests/testinstead ofsbt test, the former runs modestly fast unit tests for the JVM whilesbt testis slower because it runs cross-platform test and tests benchmark code and also compiles the documentation. - You should be able to import the project into IntelliJ as normal:
File -> New -> Project from existing sourceand pick thebuild.sbtfile.
Opening pull requests
- All code PRs should come with: a meaningful description, inline-comments for important things, unit tests (positive and negative), and a green build in CI.
- Format your code with scalafmt. Run
./scalafmtfrom the project root directory. - PRs for features should almost always include some changes to the Documentation as well.
- Be prepared to discuss/advocate-for your changes if you want them merged! You will probably need to refactor so your changes fit into the larger code base - If your code is hard to unit test, and you don't want to unit test it, that's okay, but you will need to support your case.
- The maintainers of this project might reject your changes they might rewrite them, or remove them in the future. This is normal and true for all changes regardless of the author.
- Even a rejected/reverted PR is valuable! It helps explore the solution space, and know what works and what doesn't. For every line in the repository, there exists some rejected work.
- Feel free to send Proof-Of-Concept PRs that you don't intend to get merged. Simply indicate that in the PR.
Opening issues
Please always include concrete code examples with obtained and expected output.
Releasing
- Ensure the release notes are up to date and complete.
- Pushing a git tag should trigger a release to Maven Central from the CI.