Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork27.2k
08. Reviewing pull requests
Ilkka Seppälä edited this pageJan 12, 2025 ·29 revisions
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.mdimplemented 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 theGitHub'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. SeeRecognizing contributors.
As a general guideline, pull requests with no activity during the last few months will be closed.