Skip to content

Checklist

8. PR Approval and Merging Process

Please, use the following checklist for PRs before merging it into integration. Do not forget to track spent time on reviwew to understand how much time does it take for the task to complete.

  1. Code Quality
  2. Code is clean, readable, and follows the project’s coding style guidelines.
  3. Proper naming conventions are used for variables, functions, and classes.
  4. No redundant or unnecessary code is present.
  5. Code is modular and reusable, avoiding duplication where possible.

  6. Functions and methods are concise, with single responsibilities.

  7. Documentation & Comments

  8. Code is adequately documented with meaningful comments, especially in complex areas.
  9. Public functions and methods have docstrings or inline comments explaining their purpose and usage.

  10. Any newly added or updated APIs are documented in the project documentation.

  11. Functionality

  12. All requirements outlined in the PR description/issue/task have been addressed.
  13. Code logic is sound and correctly implemented according to the feature’s requirements.

  14. New features or bug fixes do not break existing functionality.

  15. Testing

  16. Unit tests cover all new features or changes in the code.
  17. Tests pass locally, and the CI pipeline has no errors or warnings.

  18. Edge cases and error handling are tested to ensure stability.

  19. Security

  20. Sensitive information is handled securely (e.g., passwords are encrypted).
  21. No hardcoded secrets or credentials are included in the code.

  22. Input validation and sanitization are implemented to prevent security vulnerabilities (e.g., SQL injection, XSS).

  23. Performance

  24. Code is optimized for performance where applicable.

  25. No unnecessary loops, complex computations, or memory-consuming operations.

  26. Code Consistency & Standards

  27. Code follows the project’s formatting standards (e.g., PEP8 for Python).
  28. The PR includes updates to the changelog if it affects the release.

  29. Postman collection or API documentation is updated for any new endpoints.

  30. Pull Request & Merge Readiness

  31. PR description provides a clear summary and motivation for the changes.
  32. All checklists within the PR template are completed.
  33. PR is free of merge conflicts and is ready to merge following approvals.

IMPORTANT: Add a brief summary of changes and proves that you have actually tested this.

IMPORTANT: Everyone should attach the results of E2E testing as a part of the MR.

Example

LGTM! I tested the key changes, and everything is working smoothly:

Login Endpoint: Logged in with valid credentials and got a success response (200 OK) along with the expected token:

{
  "token": "JWT_token_example",
  "message": "Login successful."
}

Additionally, tried to login with incorrect credentials, and received the correct error response (401 Unauthorized) with a clear message: "Invalid email or password". The token also works as expected for accessing protected routes—no issues here! Approved.