4 exercises — responding to review feedback, clarifying ambiguous issues, reviving stale PRs, and post-merge follow-up.
0 / 4 completed
1 / 4
A maintainer reviewed your PR and left this comment: "This needs to follow the existing handler pattern rather than introducing a new abstraction." How do you respond?
Option C demonstrates professional, collaborative response to maintainer feedback:
Structure breakdown: 1. "Got it — I'll refactor" — acknowledges and commits to the change in the first sentence. No defensiveness, no qualifiers. The maintainer knows you've heard them. 2. Shows you've done the research — "looking at src/handlers/, the convention is to extend BaseHandler and register via HandlerRegistry.register()" — you read the code before asking, which respects the maintainer's time 3. Asks a targeted question — "does that look right to you?" — one specific question, not a list of questions. This tells the maintainer you're ready to act once they confirm one thing 4. States the reason for the question — "so I don't miss something structural before rewriting" — explains why the confirmation matters. The maintainer can give a specific answer or flag if there's a nuance you missed 5. Commits to a timeline — "happy to push an update today" — shows commitment and gives the maintainer confidence the PR won't stall
Why "my approach is cleaner" is harmful here: Even if your approach IS cleaner, the right time to argue for it was before the implementation, not after a review comment on an existing PR. If you believe it strongly, you can raise it as a separate issue or discussion after your PR merges. Fighting in a PR review thread is exhausting for maintainers and makes them less likely to accept future contributions from you.
Why "I'll redo it" without the question is insufficient: If you rewrite based on incomplete understanding and still miss the convention, it creates another round of review. The clarifying question is efficient, not a sign of uncertainty.
2 / 4
You found an open issue where the expected behaviour is ambiguous. Two comments suggest different implementations, and the issue is 8 months old. You want to work on it. What do you write?
Option C is the correct way to ask for clarification before starting work:
Why this message is effective: 1. Establishes intent first — "I'd like to work on this if it's still open" — saves the clarification round if the issue is already resolved 2. Demonstrates research — summarises the two approaches by reference (comment numbers, contributor handles) — shows you read the whole thread, not just the title 3. Names the specific ambiguity — "different implications for [specific edge case]" — makes the question concrete. The maintainer can answer "yes, approach A is correct for that case" in one sentence 4. States your interpretation — "my reading is that approach A better matches the original intent" — gives the maintainer something to agree or correct, rather than answering from scratch 5. "So I don't spend time going in the wrong direction" — explains why the question matters. Also signals that you understand the maintainer's time matters: a brief answer now prevents a misdirected PR later 6. "If this has already been claimed" — professional close. Acknowledges that you might be late, without being needy about it
Why "is this still an issue?" alone is insufficient: If the maintainer says "yes", you're still stuck not knowing which approach to implement. Always combine "is it still open?" with the relevant question.
The "obviously the solution is" trap: In an 8-month-old thread with competing approaches, nothing is obvious. Declaring your approach correct before confirming looks overconfident and can start the relationship on a bad footing.
3 / 4
Your PR has been sitting without review for 6 weeks. The project is active (last commit 3 days ago). How do you follow up without being demanding?
Option C demonstrates the professional stale PR follow-up:
Why this message works: 1. "Gentle ping — I know review capacity is always a constraint" — acknowledges the maintainer's reality. Open source maintainers are almost always under-resourced. This framing positions you as understanding, not demanding. 2. "No pressure" — explicitly releases the social pressure. This is not just politeness; it makes the maintainer more likely to engage because they're not being guilted into it. 3. "A few updates since I first opened it" — shows the PR is actively maintained, not abandoned. Up-to-date PRs are dramatically easier to merge than PRs that have drift from main. 4. Specific update summary — merge conflicts resolved, new test, CI green — gives the maintainer a quick re-orientation. They don't have to re-read everything to know where the PR stands. 5. "If the direction has shifted..." — explicitly opens the door for the maintainer to decline or request changes without awkwardness. This is important: sometimes a PR sits because the maintainer is uncertain how to handle it, and giving them an easy out actually unblocks the conversation. 6. "Happy to split this into smaller pieces" — large PRs are the #1 reason for slow reviews. Offering to split is an expert-level contribution technique.
Why "friendly ping?" doesn't work: It has no content. The maintainer still has to re-read the entire PR to answer. It's also slightly passive-aggressive — the question mark implies they should have reviewed it already.
When to close your own PR: If there's been no response after 2 follow-ups spaced ~4–6 weeks apart, it's professional to close the PR with a message: "Closing this as it hasn't had traction. Happy to reopen if priorities shift." This is better for the contributor (you move on) and the maintainer (backlog is cleaner).
4 / 4
A maintainer merges your PR after three review rounds. What is an appropriate response?
Option C is a professional post-merge response:
Why gratitude matters here: Maintainers do enormous amounts of invisible work. A thoughtful "thank you" after a merge is not just politeness — it signals that you valued their time and are someone they'd want to work with again.
What makes this response particularly effective: 1. Specific acknowledgement — "feedback on the handler pattern and the edge case testing" — names what was valuable. Not just "your feedback was helpful" but specifically which feedback. This shows you were listening and learning, not just accepting changes to get the PR merged. 2. "Pushed me to write a cleaner implementation than I started with" — credits the review process as an improvement, not a hurdle. Maintainers who know their reviews are valued will review your future contributions more carefully. 3. Future commitment — "planning to stay involved with the project" — signals long-term interest, not a drive-by contribution. Maintainers invest more in contributors who are likely to contribute again. 4. Specific offer — "if there are good first issues that would benefit from the approach" — offers something concrete. Not just "let me know if I can help" but a specific type of help you're equipped to provide.
Why "no response needed" is an opportunity missed: The post-merge moment is when the maintainer is most positively disposed toward you. It's the best time to express genuine appreciation and signal continued interest. A good relationship with a project maintainer opens doors — faster future reviews, mentorship, access to roadmap discussions.
Why excessive enthusiasm ("amazing!!") is counterproductive: It reads as immature in a professional context. The goal is warmth + professionalism: grateful but not gushing.