Review comments must locate specific content

What it is

Anchored review feedback ties a comment to a specific passage, version, interface element, or change rather than leaving a general verdict floating outside the work. The location is itself information: it tells the author exactly what the reviewer saw, and it lets anyone reopening the discussion later determine the comment's scope without guessing.

Why it happens

A general remark like "this is unclear" or "needs work" is inefficient not because it is impolite but because it shifts the cost of confirming what "this" refers to from the reviewer onto the author, who must first guess which passage, which version, and on what basis before any real revision can start. That confirmation step is exactly the kind of overhead grounding-cost accounts describe: two parties have to agree on a referent before the conversation can proceed, and an anchor pre-pays that cost by embedding the reference directly in the artifact — collapsing what would otherwise take several clarifying turns into a single reviewer action.

Anchoring also addresses a second failure mode. When several reviewers comment on the same material without visibility into each other's annotations, the same issue gets raised repeatedly, or reviewers reach conflicting judgments because they are looking at different versions. Making anchors visible to every participant is a social translucence move: seeing what others have already flagged, and where, is what lets reviewers avoid duplicate effort or explicitly build on each other's comments.

Anchors are not free, though. Once the anchored content is edited, moved, or deleted, the anchor can point at something that no longer exists in that form — anchor drift. Whether a system can re-locate the same logical content after a revision, typically through diff-based tracking, determines whether anchoring survives multiple revision rounds. Where the medium has no such tracking — plain text or chat threads referencing "that part" — the benefit decays fast, and a stale anchor can be worse than none: it projects a confidence about precision that the content no longer supports.

Studying it

• Paradigm: have different people locate an issue and produce a revision using only a general comment, a section-level comment, or a character-anchored comment, and compare time-to-locate, whether the revision addresses the reviewer's actual concern, and the unresolved rate.
• Variables: anchor granularity (document, section, character range), how much the content changed between comment and reading, whether the comment states observation, impact, and expected direction, revision accuracy, and discussion length.
• Methodological caution: an anchor's presence is not the same as a comment's clarity — test "can the reader find the referent" and "does the reader know what to do" as two separate measures, since they are routinely conflated; in multi-reviewer settings, track duplicate-comment rate separately, since that is the specific quantity social translucence is meant to reduce.

Where it stops holding

Anchoring works best for a genuine one-to-one relation between a comment and a location. Strategic direction, overall experience coherence, or issues that only exist across several objects have no single anchor to carry them; forcing them into an inline comment makes the problem look more local than it is, so global discussion needs its own place alongside anchored comments, not a replacement by them.

The payoff also depends on the medium's diff-tracking ability: artifacts with stable structural diffing (code, structured documents, layered design files) can re-anchor automatically or at least flag confidence loss after edits; free-text or chat-based collaboration without that tracking sees anchors go stale within two or three revision rounds, at which point shortening the review cycle matters more than anchoring itself.

At small-to-moderate reviewer counts — a handful of people on one change — anchoring measurably cuts duplication and misreading. At very large reviewer counts, such as public pull requests with dozens of potential commenters, precisely anchored comments still fragment the same underlying issue across many separate threads; anchoring alone does not converge fragmented opinion into one actionable resolution, which needs a separate merging or summarization step.

Applying it

• Attach comments to the current selection and version by default, and flag "anchor may be stale" the moment the underlying content changes, rather than silently pointing at the wrong place.
• Push comment authors to state what they observed, its impact, and the direction they expect — anchoring solves "where," not "what to do."
• Make every reviewer's anchors visible to the others, with resolve, reassign, and history states instead of silent deletion.
• Verification: have someone outside the original review locate the issue from the comment text alone and judge whether the revision answers it; track how often that fails, and how often near-duplicate comments appear, as the real measures of anchoring quality rather than anchor presence alone.

Related

• Same group: V6.04.1 Approval-chain length directly affects cycle time · V6.04.3 Rejection must give an actionable revision direction
• Nearby: V4.01 Comments and annotations · V4.04 Versions, change sets, and differences
• Search terms: anchored feedback · review annotation · common ground · social translucence