|
| 1 | +## PR Checklist - Instructions |
| 2 | + |
| 3 | +Before submitting, ensure your PR meets the following requirements: |
| 4 | + |
| 5 | +- **Compliance:** |
| 6 | + - Includes a detailed description of the changes. |
| 7 | + - Assess and state the risk (Low | Medium | High) regarding existing functionality. |
| 8 | + |
| 9 | +- **Documentation:** |
| 10 | + - Links to automated tests covering the new functionality. |
| 11 | + - Provides manual testing instructions. |
| 12 | + - Includes a GitBook documentation PR link, if applicable. |
| 13 | + |
| 14 | +- **Commit Guidelines:** |
| 15 | + - The commit message is descriptive and uses `feat:` or `fix:` prefix when needed. |
| 16 | + - Reference: https://www.conventionalcommits.org/en/v1.0.0/ guidelines. |
| 17 | + |
| 18 | +- **Testing:** |
| 19 | + - Ensures changes are covered by tests (acceptance/integration/smoke). |
| 20 | + |
| 21 | +## Review Process |
| 22 | + |
| 23 | +- PRs require thorough reviews, including code, documentation, and testing. |
| 24 | +- Manual testing is the submitter's responsibility. |
| 25 | +- For Node projects, ensure `package.json` updates align with `package-lock.json`. |
| 26 | +- Minimize dependencies; justify new ones. |
| 27 | + |
| 28 | +## PR Approval |
| 29 | + |
| 30 | +- Post-review, PRs are approved by code owners and merged by them or content writers for documentation. |
| 31 | + |
| 32 | +## Submission Fields |
| 33 | + |
| 34 | +- **What does this PR do?** |
| 35 | + |
| 36 | +- **Where should the reviewer start?** |
| 37 | + |
| 38 | +- **How should this be manually tested?** |
| 39 | + |
| 40 | +- **Any background context?** |
| 41 | + |
| 42 | +- **Relevant tickets?** |
| 43 | + |
| 44 | +- **Screenshots (if applicable):** |
| 45 | + |
| 46 | +- **Additional questions or comments:** |
| 47 | + |
0 commit comments