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
• Put status:under review badge to the pull request
• 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 Jekyll front matter on the top of the pattern's README.md implemented correctly so the pattern will show correctly on the web site?
• 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/rejectance.
• 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.

As a general guideline, pull requests with no activity during the last few months will be closed.