How to generate PR template for GitHub repo

1-create-pr-template-guide.md

In order to integrate the code review checklist into your project as a PR template, follow the below mentioned steps:

• On the main/default branch, create file pull_request_template.md inside the .github folder.
• Copy paste the checklist markdown. Commit the file.
• Once the file is pushed on main/default branch, the PR template will reflect in future PRs.

2-concise-code-review-checklist.md

Concise Code Review Checklist

• The implementation fulfills the desired requirement.
  Details

  The code does the intended while also ensuring that it does not cause side-effects or compromise the system performance and functionality.
• The code does not add unnecessary complexity.
  Details

  The code is neither too simple and long (over-engineering) nor too short and complex for peers. With a complex code, devs are likely to introduce bugs when calling or modifying the code.
• The code is style guide compliant.
  Details

  The style guide of project is followed e.g. linting, formatting, types, and other standards. Any style point differing from the guide should not be combined with other changes, as it makes it hard to see what is being changed.
• The code follows agreed design principles.
  Details

  SOLID principles are used efficiently, making the code reusable and scalable.
• The code is readable.
  Details

  The code is readable and comprehensive. Comments are clear, useful, and explain why instead of what.
• The code has appropriate tests.
  Details

  Tests should be added, as appropriate, in the same changelist as the code. Tests should be correct, sensible, and useful.
• Documentation has been updated.
  Details

  Devs should update associated documentation. If code is deleted or deprecated, then the documentation should also be deleted.
• Web accessibility standards are added.
  Details

  The UI built should support accessibility. (See WCAG checklists)

Copy the following markdown in pull_request_template.md file:

- [ ] The implementation fulfills the desired requirement.
  <details>
    <summary>Details</summary>
    The code does the intended while also ensuring that it does not cause side-effects or compromise the system performance and functionality.
  </details>
- [ ] The code does not add unnecessary complexity.
  <details>
    <summary>Details</summary>
    The code is neither too simple and long (over-engineering) nor too short and complex for peers. With a complex code, devs are likely to introduce bugs when calling or modifying the code.
  </details>
- [ ] The code is style guide compliant.
  <details>
    <summary>Details</summary>
    The style guide of project is followed e.g. linting, formatting, types, and other standards. Any style point differing from the guide should not be combined with other changes, as it makes it hard to see what is being changed.
  </details>
- [ ] The code follows agreed design principles.
  <details>
    <summary>Details</summary>
    SOLID principles are used efficiently, making the code reusable and scalable.
  </details>
- [ ] The code is readable.
  <details>
    <summary>Details</summary>
    The code is readable and comprehensive. Comments are clear, useful, and explain why instead of what.
  </details>
- [ ] The code has appropriate tests.
  <details>
    <summary>Details</summary>
    Tests should be added, as appropriate, in the same changelist as the code. Tests should be correct, sensible, and useful.
  </details>
- [ ] Documentation has been updated.
  <details>
    <summary>Details</summary>
    Devs should update associated documentation. If code is deleted or deprecated, then the documentation should also be deleted.
  </details>
- [ ] Web accessibility standards are added.
  <details>
    <summary>Details</summary>
    The UI built should support accessibility. (See <a href="https://www.wuhcag.com/wcag-checklist/" target="_blank">WCAG checklists</a>)
  </details>