We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer
We use Github to host code, to track issues and feature requests, as well as accept pull requests.
Pull requests are the best way to propose changes to the codebase (we use Github Flow).
A pull request should be small and preferably should contain only one feature.
- Fork the repo and create your branch from
master
. - Ensure the code compiles and the resulting
jar
package works as intended on different environments.gradle clean build
is preferred, but you can usemvn clean package
as well
- If you've added code that should be tested, add tests.
- Make sure any non-UI related code has at least 80% code coverage
- If you've changed configuration, update the documentation.
- Ensure the test suite passes (
gradle test
). - Make sure your code lints (
gradle check
). - Issue that pull request!
In short, when you submit code changes, your submissions are understood to be under the same License that covers the project.
If your change includes a licensed material, please update the LICENSE
.
We use GitHub issues to track public bugs. Report a bug by opening a new issue; it's that easy!
Great Bug Reports tend to have:
- A quick summary and/or background
- Application version and environment (Java version, operating system)
- Steps to reproduce
- Be specific!
- Give sample code if you can.
- What you expected would happen
- What actually happens
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
People love thorough bug reports. I'm not even kidding.
This project has a Checkstyle configuration mostly based on Java Code Conventions
- 4 spaces for indentation rather than tabs
- You can try running
gradle check
for validation