How to review pull requests as a maintainer
review principles, what to check first, leaving actionable comments, nit vs blocking comments, approving with concerns, merging strategies, squash vs rebase vs merge commit
What You Are Actually Evaluating
Review correctness first, style last. A PR that is perfectly formatted but has a logic bug is worse than one with inconsistent spacing that fixes the bug correctly.
Leaving Actionable Comments
Every comment should be specific and actionable. The note this could be better is not reviewable feedback. The note this null check needs to be before the cast on line 47 -- if token is null the cast throws first, is actionable.
Use GitHub suggestion feature for small fixes: it lets the contributor apply your fix in one click.
Nit vs Blocking
Prefix minor style comments with nit: -- they are not blocking merge. This prevents contributors from spending hours on cosmetic changes when the fix is already correct.
# Non-blocking comment
nit: Extra blank line on line 23 -- not blocking.
# Blocking comment
This function does not handle the case where options is undefined.
Calling options.timeout will throw. Add: options = options ?? {};Merge Strategies
Squash and merge -- Combines all commits into one. Clean main history. Best for small PRs. Rebase and merge -- Replays commits individually. Good for well-structured multi-commit PRs. Merge commit -- Preserves full PR history. Use when historical context matters.