29 08. Reviewing pull requests

Ilkka Seppälä edited this page 2025-01-12 14:19:21 +02:00

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.

Prefix	Purpose
feat:	Adding a new feature.
bug:	Fixing a bug.
refactor:	Code changes that neither fix a bug nor add a feature (e.g., restructuring).
style:	Changes that do not affect the meaning of the code (e.g., formatting, linting).
test:	Adding or modifying tests.
doc:	Documentation-only changes (e.g., README updates).
chore:	Maintenance changes (e.g., build process, tooling, dependency updates).
perf:	Performance improvements.
ci:	Changes related to continuous integration (e.g., GitHub Actions, pipelines).
hotfix:	Urgent bug fixes that require immediate deployment.
security:	Security-related changes (e.g., fixing vulnerabilities).
config:	Configuration changes (e.g., .env, .gitignore, etc.).
build:	Changes related to the build system (e.g., upgrading dependencies).
deps:	Adding, removing, or updating dependencies.
release:	Version bumps or release-specific changes.
i18n:	Internationalization or localization updates.
ux:	User experience improvements (e.g., UI changes).
wip:	Work in progress. Commit is incomplete but pushed for collaboration.
revert:	Reverting a previous commit.
prototype:	Experimental or proof-of-concept code.
analytics:	Adding or updating analytics or metrics.
deps-dev:	Development-only dependency updates.

• 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.

Home

01. How to contribute

03. Coding conventions

05. Collaboration

06. Working with issues

07. Categories and Tags

08. Reviewing pull requests

09. Team

10. Technology selections & decisions

11. Static analysis

12. IDE instructions

13. Roadmap

15. Support for multiple languages

17. Recognizing contributors

21. New Pattern Template