Learn how to review PRs like an expert
summary
Podman reviewers handle an average of 200 PRs/month and focus on concrete signals: prioritize clear titles to triage, reject or request more eyes if a change doesn’t fit project goals before reading code, prefer big-picture diffs or commit-by-commit depending on comfort, and phrase feedback as ask questions not dictate. Reviews check (1) should we have it, (2) is it implemented correctly, (3) is it maintainable; use video calls for sticky disagreements, linters for style, and treat AI-generated patches like any other.
AI-written summary · about
chapters (18)
- 0:00Reviewing PRs in open source
- 1:06Why PRs matter for projects
- 3:12Matt’s PR review approach
- 7:21Milislov’s PR review priorities
- 9:32Disagreements in PR reviews
- 13:21Starting PR reviews
- 15:08What reviewers expect
- 18:17Where experts have no edge
- 19:00Constructive feedback tips
- 21:12AI-generated PRs
- 24:09Code style vs nitpicking
- 26:20AI review tools
- 27:50Technical disagreements
- 29:17Failed review approaches
- 30:41Avoiding PR review burnout
- 31:33Accepting review imperfections
- 31:56Reviewer-submitter conflicts
- 34:12Liking an idea but disliking the implementation
related talks
01h 05mGetting Good (or Better) at Code Reviews
18mHow to effectively create and review PRs
29mThe Art of Humanizing Pull Requests (PR’s)
21mContinuous Improvements of The Code Review Process
38mPull Requests and Reviews for Good
23mDrama-Free Code Review!
30mEffective Pull Request Reviews
47mGoldilocks and the Three Code Reviews