PR Review Process

Reviewing Pull Requests (PRs) is an important part of collaboration.
A strong review helps ensure code quality, prevents bugs, and supports your teammates.

This guide explains how to review a PR, how to test it locally, and how to leave meaningful feedback.

---

🎯 Before You Begin

Navigate to the repository’s Pull Requests tab and look for PRs labeled as needing review.

Example:

Open the PR and review the description.
A good PR description should tell you:

• What changed
• Why it changed
• How to test the changes
• Any dependencies required
• Screenshots of UI (if applicable)

If this information is missing, ask the PR author for clarification before reviewing.

---

🔍 Step 1: Switch to the PR Branch and Test Locally

Every PR lists the branch it was created from:

To test locally:

git fetch
git checkout <branch-name>

Next, install or update dependencies if needed:

npm install
npm update

⚠️ If the project doesn’t run, the most common cause is missing or outdated packages.

Once the branch is running:

• Test the feature(s) described in the PR

• Compare expected behavior vs actual behavior

• Take screenshots or a short video if helpful

• Note anything that seems broken or unclear

If instructions for testing are not clear, leave a comment asking for details.

🗂 Step 2: Review the Code Changes

Navigate to the Files Changed tab:

Look for:

• Clean, readable code
• Proper naming conventions
• Repeated logic that should be abstracted
• Potential security issues
• Missing error handling
• Files that do not belong in the PR (build artifacts, .env, images in wrong folders, etc.)
• Adequate comments where logic is complex

If something needs clarification or improvement, leave a line comment directly on that section of code.

---

🧭 Step 3: Leave Your Review

Click Review Changes:

Choose your review type:

✔️ Approve

The PR meets all requirements and is ready to merge.

💬 Comment

General feedback or questions that don’t block merging.

🔧 Request Changes

Something is incorrect, incomplete, or unclear and requires updates before merging.

When writing your review:

• Be specific and constructive
• Suggest improvements when possible
• Focus on code quality, not personal criticism
• Ask questions if anything is unclear
• Provide screenshots or examples if helpful

Example comment:

This looks good overall. Consider extracting this repeated logic into a helper function to reduce duplication.

---

💡 Best Practices for Reviewing PRs

• Always run and test the branch locally.
• Follow the PR description closely when testing.
• Leave clear, actionable feedback.
• Only approve when all acceptance criteria are met.
• Ask for missing information rather than guessing.
• Be thorough but kind—reviews are learning opportunities.

---

⚠️ Common Mistakes

Mistake	Why It Matters
Approving without testing locally	Introduces bugs into the main branch
Leaving vague comments	Confuses the PR author and slows progress
Ignoring missing instructions	Reduces accountability and consistency
Being overly harsh	Discourages collaboration and learning
Reviewing only the code, not behavior	UI, UX, or logic bugs go unnoticed