PR rules

Here are some general rules for pull requests:

1. If PR fixes some issue, this issue has to be referenced from the first comment in the PR.
2. In 99% of cases PR should contain only one commit, so any additional commit should be squashed or amended. Use git rebase -i HEAD~N (where N is a number of commits to analyze) to amend/rebase/squash your commits.
3. Before sending a PR make sure that your changes pass mvn clean verify. Please note that commit message is also validated.
4. Usually PR is not reviewed until all Continuous Integration (CI) checks are passed, please review CI status after PR is created. If you are uncertain on a CI failure, please check with an admin for help.
5. If any check's functionality might be affected, then diff report should be provided to prove that no negative regression happened: https://github.com/checkstyle/contribution/tree/master/checkstyle-tester#checkstyle-tester .
6. Reply to each point raised by a reviewer. Reviewers will mark change requests as resolved when they review the changes.
7. Use present simple tense for a commit message.
8. If you made changes requested by reviewer, push them to the branch and PR and CI will automatically update.
9. Do not close and create a new PR for any reason (like additional changes, rebasing, merging, etc) unless instructed to by a reviewer.
10. Do not close and re-open the same PR constantly. It will not re-run the CI and only serves as noise. Only pushing more commits, or an amend and force push of the existing commit, will trigger the CI to run again.
11. When making updates to your PR, always rebase on the latest master especially if there are any new changes in master since your PR creation. This helps avoid any unexpected issues once the PR is merged with other people's changes.
12. Users may not create more than 3 Pull Requests (PRs) if changes are still being requested of them. We ask if you have time to do more, than atleast make sure your CI is passing before uploading more. If you have more free time, we recommend you get more familar with Checkstyle's code and how it works, especially for areas you plan to consider for the GSoC projects.