I have reviewed a few thousand pull requests. The ones that went well had very little to do with how right I was, and a lot to do with how the comment read to a person who was tired, on a deadline and proud of the work.

Say what you understood first

Half of all review arguments are two people describing different code. One sentence at the top removes most of them: this moves the price calculation to the server and keeps the old path behind a flag. If that sentence is wrong, the author learns something important before I have criticised anything.

Separate must from would

I mark every comment. It takes five characters and it changes the whole conversation.

must:   this drops the aria-label, so the icon button has no name
should: the retry lives in three places now, worth one helper
nit:    name could say what it returns
ask:    why a ref here and not state? I may be missing something

A review with one must and six nit lines is an approval with homework. A review with seven unmarked comments reads as seven objections.

Approve more than you block

• If the change is safe and better than what was there, I approve and leave the comments.
• If I would have done it differently but it works, I say so once and approve.
• I block for correctness, accessibility and anything that is expensive to undo.

Review the description too

The pull request text is the only documentation most changes ever get. I ask for three things in it: what changed, how to see it, and what was deliberately left out. When the description is good I can review the idea first and the code second, which is the right order.

A review is a small piece of writing with one reader. Treat it like one and most of the friction goes away. The juniors on my last team started copying the prefixes within a month, and review time fell by about a third.