Alex: Welcome back. Challenge 12 is Review Like a Pro, and this is where the workshop starts to feel like real collaboration. You are going to review a pull request from a classmate, a peer-simulation PR, or a sample file, and leave feedback that another person could actually use.

Jamie: I like the goal, but review can feel weirdly personal. It is someone else's work, and you are putting your opinion on it in public.

Alex: Exactly, and that is why this challenge is about both code review and open source culture. A good review is not a performance of expertise. It is asking useful questions, noticing what works, suggesting improvements, and assuming the author was trying to do a good job.

Jamie: So the target is not to sound impressive. It is to help the change get better without making the author feel attacked.

---

Alex: Before you start, make sure you are in the right place. Day 2 work happens in your Learning Room repository, which is provisioned for you, and VS Code is the required editor for the Day 2 local workflow. If you joined Day 2 without Day 1, the quick start guide is there to confirm your account, tools, and GitHub basics before you jump in.

Jamie: And if I do not have a classmate PR ready, I am not stuck, right?

Alex: Right. The challenge gives you options. You can review the peer-simulation PR named Peer Simulation: Improve contribution guidance, you can review a buddy's Day 2 PR if your facilitator gave you access, or you can use docs/code-review-sample.md as the practice material.

Jamie: And the evidence is not mysterious. I need the review URL, a short description of the feedback I gave, and the verdict I chose.

---

Alex: On GitHub.com, start from the Pull requests tab in the repository. Open the PR you are reviewing, then move to the Files changed tab. Along the top of a pull request you will usually hear or see Conversation, Commits, Files changed, and Checks.

Jamie: Files changed is where the actual review happens, because that is where the diff lives.

Alex: Yes. A diff is the comparison between the old version and the proposed new version. GitHub marks removed lines and added lines, and it also uses red and green visually, but the important thing is the line-level change: what was removed, what was added, and where it happened.

Jamie: What do I do first when I land in that file list?

Alex: Orient yourself before commenting. Read the PR description, use the file tree to hear which files changed, then move through the changed files one at a time. Some learners like Focus Mode in the browser because it reduces noise while reading diffs.

Jamie: Then I place the first inline comment on a specific line, not just at the bottom of the PR.

Alex: Exactly. Focus on a changed line, or hover over it if you use a mouse, and activate the blue plus comment button. For the first comment, make it specific and positive, like: Great, this heading structure makes the section easy to scan.

Jamie: That is much more useful than just saying looks good.

Alex: For the second comment, make a constructive suggestion. You might say that a sentence would be clearer if it used the word beginners instead of new people. If the suggestion button is available, the one with the plus and minus style icon, use it to create a suggestion block so the author can accept the exact text change.

Jamie: That one-click acceptance is a nice accessibility win too. It reduces the amount of retyping and interpretation the author has to do.

---

Alex: At the end, submit a review verdict. Approve means the changes are ready to merge. Request changes means something must be fixed first. Comment means you have feedback, but you are not blocking the merge.

Jamie: When I am unsure, Comment is the safer choice. It lets me participate without pretending something is blocking.

Alex: That is a strong default for practice reviews. A complete review might say: Nice work. The structure is clear and the content is welcoming. I left one suggestion to improve clarity. If there is a real blocker, name it clearly, such as a missing required field, an insecure http link that should be https, or a heading level that breaks the document structure.

Jamie: So review comments can be praise, questions, suggestions, or required changes. The key is that each one points to something specific.

---

Alex: You can also do this from VS Code with the GitHub Pull Requests and Issues extension. Install it from the Extensions sidebar with Ctrl+Shift+X, or use the Command Palette with Ctrl+Shift+P and search for the extension. On Mac, use Cmd instead of Ctrl for those shortcuts.

Jamie: After installing, I sign in to GitHub, and then I should see a GitHub section in the Explorer or a Pull Requests view in the Activity Bar.

Alex: Right. From there, find an open PR, preferably one that is not yours, and open it. You can check out the PR branch locally for testing, open the changed files, and read the diff inside VS Code.

Jamie: The diff editor can be a lot through speech, though.

Alex: Use the Accessible Diff Viewer. Press F7 to move to the next change and Shift+F7 to move to the previous change. It reads each change as a structured block, which is usually much easier than arrowing through a visual side-by-side diff.

Jamie: And to comment, I put the cursor on the line, run GitHub Pull Requests: Add Comment from the Command Palette, write the comment, then add it. Ctrl+Enter can submit in some comment boxes.

Alex: When you are done, use Finish Review, the check icon at the top of the PR view. If checkout fails because you do not have permission, stay in read-only mode and open the PR on GitHub.com. The browser path still completes the challenge.

---

Jamie: What am I actually looking for when I review? I know I should be helpful, but helpful about what?

Alex: Start with whether the change does what the PR description says. Then check whether the commit message is meaningful, whether there are typos or formatting issues, whether a beginner would understand the content, and whether the language and Markdown are accessible. If the PR includes a template, notice whether the title, description, related issue, testing notes, and checklist are filled in well enough to guide the reviewer.

Jamie: How many comments is too many?

Alex: Enough to help, not enough to bury the author. If five comments all point to the same pattern, leave one example and say it happens in a few places. Also set expectations with words like nit, question, suggestion, or blocking, so the author knows how seriously to treat the comment.

Jamie: That also helps with tone. A nit about capitalization should not sound like a security emergency.

Alex: Exactly. Helpful feedback usually starts by acknowledging what is working, identifies the specific concern, explains why it matters, suggests a path forward when you can, and signals the weight of the concern. Talk about the code or the document, not the person. If you are uncertain, use tentative language like: I might be missing something, but...

---

Jamie: There is also a command line path here, right? Some people like staying in the terminal.

Alex: Yes. With GitHub CLI, gh pr list shows open pull requests, and gh pr diff followed by the PR number shows the changes. For a summary review, you can run gh pr review with the PR number, --comment, and a body message. GitHub CLI can also approve or request changes, and advanced reviewers can add more specific comments, but for this challenge the browser or VS Code path is usually clearer.

Jamie: What about Copilot during review? Is it fair to ask it what changed?

Alex: It can be useful as a reading aid. In VS Code, with a diff open, you can ask Copilot to summarize the change or explain a piece of code you do not understand. But do not outsource judgment. You still verify the diff, check the project norms, and decide what feedback is appropriate.

---

Alex: After you submit the review, the author sees your comments on the PR. They may reply, make commits, resolve threads, or re-request review after changes. A maintainer handles merging when the project is ready, usually after review and status checks pass.

Jamie: And if I am the author receiving feedback, I should say thanks, ask clarifying questions, explain my choices when needed, and surface blockers early.

Alex: That fits the bigger GitHub Flow pattern: create a branch, make a small focused change, open a pull request, discuss and review, pass checks, then merge. GitHub Flow keeps main deployable and makes the PR the place where the conversation lives. One branch should represent one task, and small PRs get reviewed faster.

Jamie: There are project norms around that conversation too.

Alex: Yes. Read the README, CONTRIBUTING file, Code of Conduct, security policy, and license when they exist. Good first issue labels are an invitation to start small, not a promise that maintainers have unlimited time. Clear commit messages, focused changes, and a PR description that says what changed, why, and how to test it make the review kinder for everyone.

Jamie: And if things get tense?

Alex: Slow down. Public, written, asynchronous communication can make tone hard to read. If you receive harsh feedback, look for the actionable part and ask for clarification. If you disagree, explain the tradeoff respectfully. If someone is rude, follow the project's Code of Conduct. If you caused offense, acknowledge it, apologize briefly, and repair the conversation.

---

Jamie: Let us talk about the stuck moments, because review interfaces have a lot of little controls.

Alex: If you cannot find the Files changed tab, open the PR first and then look for the tab links near Conversation and Commits. If you cannot leave an inline comment, focus on the line number in the diff and look for the blue plus button. If the suggestion icon is not available, leave the exact replacement text in your comment instead.

Jamie: And if there are no classmate PRs?

Alex: Ask a facilitator for a sample PR or use the peer-simulation PR and docs/code-review-sample.md. If the VS Code extension does not install cleanly, reload the window from the Command Palette. If sign-in fails, confirm you are signed in to GitHub in the browser, restart VS Code, and try again. If the PR list looks empty, switch the Pull Requests view to show all open PRs.

Jamie: Then I paste the review URL into the challenge issue, describe my inline comments, name my verdict, and close the issue when instructed.

Alex: Yes. If you are using the peer simulation, also read any review comments on your own PR, or reply with one thing you learned if you do not have real buddy access. Gandalf celebrates once your review is approved, and Challenge 13 unlocks after you confirm the review and close the issue. The win is not the number of comments. It is one specific, constructive review that helps another contributor move forward.