Approve a pull request as a PM: comments and suggestions

A product person reviews the change as a customer will meet it, not the code. Four questions cover most of it:

1. Does it do what the issue asked?
2. Does the copy read right: the wording, the tone, the grammar?
3. Does it do anything the issue didn't ask for?
4. What happens in the cases nobody wrote down?

Leave the code to engineers: naming, structure, performance, which library or pattern fits. On #134, Oscar reviews those and has already approved. Your review answers a different question: “is this the right change for customers?”, not “is this good code?”.

If something in the code still looks odd to you, ask a question instead of giving an instruction. “Why does a bug fix touch styles/checkout.css?” is a fair product question. “Rename this function” is a call you can't judge, and it only adds noise to the review.

That split is why CatChow asks for two reviewers on anything customers will see: one for the code, one for the product.

Review where customers will meet the change: on the preview, the temporary copy of the site that the preview check builds for the branch. Open its link on the device your customers use most; at CatChow that's a phone.

First follow the author's “How to test” steps exactly. They prove the happy path works. Then try the edge cases: the less common paths through the same feature, the ones nobody wrote down. For a cart fix, that means:

• removing items one by one with the minus button instead of the bin;
• applying a promo code, then changing a quantity;
• editing the same cart in two browser tabs;
• emptying the cart completely.

Stay inside the feature the pull request touches. The home page logo or the delivery page aren't part of #134, so checking them proves nothing about this change. Reading the test file is the engineer's part of the review.

Write down what you tried. The list goes into your review summary, and it tells the author which cases are already covered.

In Files changed you don't have to read every file. Each file has a Viewed checkbox (as of 2026): tick the ones you've checked or left to others, and they fold away. On #134 the component and the test are Oscar's; the copy file and the stylesheet are yours.

To comment on a line, hover over it and click the blue +, or drag across several lines. A comment box opens right under the line with two buttons:

• Add single comment posts at once and notifies the author.
• Start a review keeps the comment as pending, so you can add more and send them all together with a verdict.

Pending comments carry a Pending mark, and only you can see them until you submit the review. The author gets everything in one notification, with your verdict on top.

Prefer reviews to single comments. Five single comments are five pings in the middle of someone's work; one review is one ping with your whole thought in it.

When the fix is a few exact words, don't describe it. Write it. The comment toolbar has a suggested change button (as of 2026, a small icon with a plus and a minus). It inserts a suggestion block containing the current line, ready for you to edit:

```suggestion
  "checkoutDisabledHint": "Your cart is empty. Add a treat to check out.",
```

Below the block, add a one-line reason: “check out” is the verb, and the tone is friendlier.

The flow: open Files changed, click the blue + on the line, insert the suggestion, edit the line, add the reason, Start a review, and finally submit the review with a verdict.

The author sees a mini-diff with a Commit suggestion button. One click turns your line into a commit on their branch, and GitHub lists you as co-author. Several suggestions can go into a single commit with Add suggestion to batch.

A suggested change replaces exactly the lines you commented on with exactly the text you wrote. That makes it perfect for small, exact fixes: a word in the copy, a typo, a number, a link, a label on a button. You know the right answer, and the author only has to agree.

It's the wrong tool for anything bigger. If the checkout flow needs a different step, if a whole screen should behave differently, or if the fix spans several files, a suggestion can't hold it, and you probably shouldn't pick the solution anyway. Describe the problem instead: what you saw, why it matters to customers, and what a good outcome looks like. Then let the author choose how to get there.

The same goes for code you can't judge. Suggesting a different function name or a rewritten condition looks helpful but turns a product review into an engineering one.

Rule of thumb: if you can write the final text in one line and explain it in one sentence, suggest it. Otherwise, describe it.

The scope check compares three things: the issue, the description and the diff. Anything in the diff that neither the issue nor the description mentions gets a question, never a silent approval.

In #134 the issue asked for a working checkout button. The diff also changed styles/checkout.css: the main button of the whole shop went from green to orange. Nothing technical stops that from merging. The problem is that it's a visible change for every customer, hidden inside a bug fix that nobody will read as a redesign.

Why that matters for a product team:

• If orders drop next week, nobody will know to look at a “bug fix”.
• The effect can't be measured; it deserves a proper A/B test with its own issue.
• Reverting the colour would also revert the fix, because both live in one pull request.

So ask the author to split it out. A good scope question is friendly and specific: what's extra, why it matters, and where it could go instead.

Remember who reads your review: a colleague who spent three days on the change and opens your comments at six in the evening. A few habits make comments easy to act on:

• Comment on the change, not the person. “What's the reason for the colour change?” asks the same as “Why did you do this?”, without sounding like an interrogation.
• Say why, not only what. “This is wrong” gives the author nothing to fix.
• Ask when you're unsure. “What happens if a promo code expires while the cart is open?” is a real question, not a hidden accusation.
• Mark small things as optional. Start with “Optional:” (some teams write “nit:”) so the author knows it won't block the merge.
• Say what's good. “The hint shows exactly when the cart is empty, nice” tells the author what to keep.

A good comment is specific, gives a reason and offers a way forward. Tone isn't decoration: comments people are glad to get are the ones that get acted on quickly.

Your comments are pending until you submit the review. Use the review button at the top of Files changed: as of 2026 it says Submit review (older layouts say Review changes). It opens a box for a summary and three options:

• Comment: feedback or questions without a verdict.
• Approve: this can be merged.
• Request changes: something must change before it's merged.

Start a review and Add single comment come earlier: they decide whether a comment waits for your verdict or goes out alone. The verdict itself is always one of the three above.

The same verdicts exist in a terminal: gh pr review 134 --approve, gh pr review 134 --request-changes -b "..." and gh pr review 134 --comment -b "...".

People often write “LGTM”, “looks good to me”, in an approval. Fine, as long as it's true: an LGTM on a pull request nobody opened is the worst review there is. And Request changes isn't rude. It's precise: the author knows exactly what blocks the merge instead of guessing from a pile of comments.

Choosing the verdict comes down to one question: must anything change before customers get this?

• If the change works and your remaining notes are small and optional, Approve and leave the notes as optional suggestions. The author can apply them now or skip them.
• If something would hurt customers or wasn't asked for, such as a visible colour change, a wrong price or a field shown where it shouldn't be, Request changes and name that blocker in the summary.

Two mistakes sit on either side. Requesting changes over a comma holds up a working fix for a matter of taste. Approving while hoping someone else catches the real problem hands the risk to customers.

The summary is the first thing the author reads, above your line comments. Write it in two to four sentences: what you tried, what works, what blocks (if anything) and why, and which notes are optional. With that, the verdict and the comments tell the same story.

Branch protection, or a ruleset in newer settings, is a list of rules GitHub enforces on a branch. At CatChow, main has five:

• changes only through pull requests;
• at least one approving review;
• the build and test checks must pass;
• every conversation resolved;
• the branch up to date with main before merging.

Two details trip people up. First, a Request changes review from someone with write access holds the merge, even when the approval count is met. It clears when that reviewer approves after the fix, or when someone with the right permissions dismisses the review. Second, authors can't approve their own pull requests, and only reviews from people with write access count towards the rule.

After the author fixes things, they re-request your review (the arrows next to your name). Each comment thread has a Resolve conversation button; at CatChow, whoever opened a thread resolves it once satisfied. Then you approve, and the merge box can turn green.