Peer Review Checklist¶

Use this checklist when reviewing a teammate's code. It combines the Agile concepts from Lesson 01 and the bug-reporting practices from Lesson 02.

1. Before You Review¶

[ ] Card in Review column – Confirm the task is moved to the Review column of the Kanban board so WIP limits are respected.
[ ] CI status is green – Automated tests must pass before you spend time on a manual review.
[ ] Descriptive pull request – The author should link to the related issue and summarize the change.

[ ] Understand the purpose – Read the description and commits to know what problem is being solved.
[ ] Check style – Verify the code follows the Code Style Guide and includes docstrings.
[ ] Look for bugs – Run the code locally and note any unexpected behavior. If you find an issue, document it using the bug report template.
[ ] Readability and design – Ensure variables and functions are clearly named and logic is easy to follow.
[ ] Tests updated – Confirm unit tests cover new or changed functionality.

[ ] Use inline comments – Point to specific lines and explain your reasoning. Be concise and constructive.
[ ] Summarize in the review – Outline major concerns or approvals at the top of your review comment.
[ ] Reference resources – Link to documentation or examples if it helps the author improve.
[ ] Stay positive – Follow the tone guidelines in the Merge Request Feedback Style Guide.

[ ] Request changes if needed – Mark the review as "Changes requested" until issues are addressed.
[ ] At least one peer + one mentor – A pull request requires approval from another intern and a mentor before merging.
[ ] Move the card – Once merged, move the Kanban card to Done and note any follow-up tasks.

Consistent peer reviews keep code quality high and help everyone learn. Use this checklist every time you review a pull request.