08. Reviewing pull requests

Reviewing incoming pull requests is an open process where anyone can participate and give improvement suggestions. That being said, accepting a pull request can be done by a core team member. The general guidelines for code review are given below.

As a reviewer, you need to follow these steps

Assign the pull request to yourself
If the issue is not mentioned in the pull request, mention it. That way it's easy to later link back to the PR.
Check that the code compiles and the existing tests succeed (CI build does this)
Does the example code implement the pattern correctly and follow good coding practices?
Does the example code have proper tests and enough test coverage?
Is the example code commented well enough, including a general pattern/example description in App.java?
Is the YAML front matter on the top of the pattern's README.md implemented correctly so the pattern will show correctly on the website?
Are the categories and tags set correctly in the pattern's README.md?
Is the pattern well enough described in README.md?
Based on the checks above use the GitHub's review functionality to signal your acceptance/rejecting.
Please add one of the tags mentioned below (type label) as the prefix before squashing and merging the code to the repository.
- bug
- enhancement
- feature
- refactoring
- support
- task
- docs
- translation
When the pull request is merged, set the milestone (e.g. we are working on 1.23-snapshot -> set the milestone to 1.23)
Check the affected issues and close them where necessary. Also to the closed issues set the milestone as described above.
Finally, recognize the contributors if they are not already listed. See Recognizing contributors.