Submitting Pull Requests

Thanks for the code submission! Being an Open Source project means anyone can submit code changes to fix issues or add enhancements. All Pull Requests will need to be approved by one of the RPTools Core Developers, but before doing so you will need to follow some simple guidelines.

1. It will need to pass all checks. This means our Continuous Integration will spawn and attempt to build your Pull Request. A common cause for failure is code formatting. Be sure to run ./gradlew spotlessApply before checking in your code to insure your code formatting follows our standards! It's important that everyone follow the same formatting rules to prevent PRs from including textual changes that don't need to be made.

   • Note that spotlessApply does not correct everything that the RPTools prefers in terms of formatting.
   • One issue is that single-line IF statements are inappropriate.
   • Whether a single-line true or false block should be surrounded by braces is somewhat in the air.

2. All changes should have an open GitHub Issue and the commits should mention the issue by number, like "Added i18n strings to fix issue #206". Comment on an Issue before working on it to have it assigned to you so that multiple people don't work on the same issue (unless needed!). The Reviewable feature of GitHub means that comments made by reviewers about your code will appear in the PR discussion instead of the Issue. Our goal is that review comments in the PR should be strictly about the code, while comments about why or whether something is done should be in the Issue discussion.

3. Use keywords Fixes, Fixed, Closes, or Resolves followed by the Issue number, eg Fixes #132 This will allow GitHub to auto close the linked Issue when the Pull Request is merged.

4. Branch management for pull requests:

   1. PRs for new features should always be against the latest development branch, which we name develop.
   2. PRs for bug fixes should always be made against the latest stable branch (unless your bug fix is for a not-yet-stable feature, of course).
   3. You may be asked to resubmit a PR that isn't made against the correct branch. If your PR is simply out of date with respect to our repo, you can run a fast-forward merge on your personal repo to bring your PR up to speed (potentially correcting any conflicts that may occur).