-
Notifications
You must be signed in to change notification settings - Fork 11
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
baab9a6
commit e0f4329
Showing
1 changed file
with
65 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,65 @@ | ||
# Standard PR Review Checklist | ||
|
||
## PR Meta Information | ||
|
||
- **PR Title**: Ensure the PR title is clear, concise, and adheres to the project's naming standards (e.g., `[Feature] Add X`, `[Bugfix] Fix Y`, `[Refactor] Z`). | ||
- **Description**: Include a detailed description explaining: | ||
- What the PR does. | ||
- Why the changes are necessary. | ||
- Links to related issues, tickets, or tasks (if applicable). | ||
- **Checklist in Description (Optional)**: Include a checklist of tasks completed (if the project uses task checklists). | ||
- **Reviewer Assignment**: The PR must be assigned to at least one reviewer. | ||
- **Labels/Tags (Optional)**: Ensure the PR has appropriate labels/tags (e.g., `Bugfix`, `Feature`, `Documentation`). | ||
|
||
## Code Changes | ||
|
||
- **Scope of Changes**: | ||
- PR should contain changes related to only one feature, bugfix, or task. | ||
- Avoid mixing multiple unrelated changes in one PR. | ||
- **Clean Code**: | ||
- Code should follow the project's coding standards (naming conventions, indentation, spacing). | ||
- Ensure proper formatting (auto-format code if tools are available). | ||
- **No Repetition**: Avoid duplicate code; refactor into reusable functions or components where possible. | ||
- **No Hardcoded Values**: Replace hardcoded values with constants, environment variables, or configurations. | ||
|
||
## Quality and Best Practices | ||
|
||
- **Tests**: | ||
- Ensure unit tests or integration tests are added/updated for the feature or bugfix. | ||
- Run all tests and confirm they pass locally. | ||
- **Linting and Static Analysis**: | ||
- Code should pass all linting checks (e.g., ESLint, Flake8, etc.). | ||
- Resolve any warnings or errors flagged by static analysis tools. | ||
- **Error Handling**: Ensure proper error handling is implemented (avoid swallowing errors silently). | ||
- **Performance Considerations**: Check for code efficiency (e.g., avoid unnecessary loops, database queries, or API calls). | ||
|
||
## Compliance | ||
|
||
- **CI/CD Pipelines**: | ||
- Ensure all CI pipelines (builds, tests, deployments) pass successfully. | ||
- Attach a CI screenshot if the pipelines aren't integrated into the PR system. | ||
- **Security**: | ||
- Verify no sensitive information (API keys, passwords, etc.) is exposed in the code or configuration. | ||
- Check for usage of secure methods and libraries. | ||
- **Backward Compatibility**: Ensure the changes don't break existing functionality or introduce regressions. | ||
|
||
## Documentation and UI | ||
|
||
- **Documentation (Optional)**: Update relevant documentation (e.g., README, API documentation, comments) for new features or changes. | ||
- **Screenshots/Videos (Optional)**: | ||
- Add screenshots or video recordings for UI changes (if applicable). | ||
- Ensure the UI matches the design and is responsive on different screen sizes. | ||
|
||
## Miscellaneous | ||
|
||
- **Dead Code**: Remove any unused code, variables, or imports. | ||
- **Debugging Artifacts**: Ensure no debugging code (e.g., `console.log`, `print`) is left in the codebase. | ||
- **Dependencies (Optional)**: | ||
- Verify no unnecessary or outdated dependencies are introduced. | ||
- Lock file changes (e.g., `package-lock.json`, `requirements.txt`) should be reviewed. | ||
|
||
## Final Checks | ||
|
||
- **Self-Review**: The developer submitting the PR must perform a thorough self-review before assigning it to a reviewer. | ||
- **Cross-Environment Testing (Optional)**: Confirm the changes work in multiple environments (e.g., dev, staging, production). | ||
- **Feature Flags (Optional)**: Ensure new features are behind feature flags if they are not fully ready for release. |