GitHub resolve conversation etiquette: who closes the thread, and why it matters

Every team that reviews code on GitHub eventually has the argument, usually in a PR thread that was already tense. Someone hits the GitHub resolve conversation button on a comment they did not write, and the person who wrote it notices. Was the concern addressed, or dismissed? GitHub is no help here: the button collapses the thread and marks it resolved, and the platform is agnostic about who clicks it. The etiquette is entirely a team norm, which means most teams have three conflicting norms and no document.

The GitHub resolve conversation norm nobody writes down

There are two coherent positions. Author-resolves says the author is the janitor of their own PR: they act on feedback, they tidy the threads, and a wall of resolved conversations signals a change that is ready. Commenter-resolves says a thread is a question addressed to its author, and only the person who asked can say the answer satisfied them. Both work when everyone shares the assumption. What breaks teams is the mixture: an author who thinks resolving is bookkeeping meets a reviewer who thinks it is an answer to their question being closed unread. The classic Microsoft research on modern code review found that review is as much a communication channel as a defect filter, and the resolve button is part of that channel; clicking it transmits something whether you intend to or not.

What the ambiguity actually costs

The cost lands at re-review time. A reviewer coming back after the author pushes fixes faces a stack of threads in mixed states: some resolved by the author, some open but answered, some open and forgotten. Which ones still need their attention? If resolved might mean “fixed and verified” or might mean “the author decided it was fine,” the reviewer has to reopen and reread everything to be safe, which is precisely the wasted pass we describe in re-reviewing pull requests. Unresolved-thread limbo has a second failure mode: PRs that merge with open threads nobody can later interpret. Six months on, an open thread that says “this will break under concurrent writes” with no reply is either a landmine or noise, and nobody can tell which. The archaeology cost is real: someone eventually spends an afternoon reconstructing whether a warning was heeded, and the thread state could have answered in one glance.

A defensible default

The protocol that keeps the signal clean:

• The author replies to every thread, even trivially: “fixed in the next push,” “disagree, here is why,” or “good catch, done.” A push with no reply forces the reviewer to diff-hunt for whether their comment was acted on.
• The author pushes the fix and references it in the reply when the fix is not obvious.
• The commenter resolves. They raised the concern; their click is the confirmation it was met. Resolution becomes a tiny handshake instead of a unilateral declaration, and the resolved state acquires a precise meaning: the person who asked is satisfied. That precision is the entire point of having a norm.
• Stale threads default to a ping, not a resolve. If the commenter goes silent for days, the author asks once, then resolves with a note. Silence should not block merges forever, but the note preserves the record.

The exceptions that prove the rule

Commenter-resolves is the default, not a ritual. Feedback the reviewer explicitly marked as optional, the Conventional Comments style of nit: or suggestion (non-blocking):, transfers the decision to the author, and with it the resolve. Making the author round-trip every take-it-or-leave-it comment back to the reviewer is ceremony with no information content, and it is how teams learn to hate the protocol. The prerequisite is honest labeling: reviewers have to actually mark their nits as nits, a discipline we cover in our piece on nitpicks. The other sane exception is threads the commenter is no longer around to resolve; departed colleagues should not hold locks on your merge button.

Write the norm down

Whatever you choose, choose it in a document instead of in each PR separately. Two sentences in the contributing guide end the argument permanently: who resolves, and what the exception for pre-labeled nits is. New hires absorb it in their first PR instead of guessing, and nobody has to litigate intent inside a thread that is already about something else. This is the general lesson of healthy review culture: friction comes less from strictness than from unstated rules enforced inconsistently. A team that resolves threads predictably gets a concrete payoff, because thread state becomes trustworthy. Resolved means confirmed, open means pending, and a re-reviewer can navigate by that state instead of rereading the whole conversation. It is a one-line policy that buys back real review time every single week.