Do The Work Before You Offer It

Do the work before you offer it

Purpose

A conditional offer feels like deference and reads like collaboration, so it survives every pass of a draft. But it converts your machine time — which is abundant — into the reviewer's attention, which in every house measured is the actual constraint on merging. Worse, it arrives without the information that would let them answer well: "should I fix the others?" is unanswerable until someone knows how many there are, whether one change covers them, and whether the suite still passes. Doing the work produces that information as a by-product, and then there is nothing left to ask.

The asymmetry is the whole point. A reviewer has judgement, context and merge rights; what they lack is an hour of unattended compute. That is exactly what an offer withholds and a finished patch supplies.

When to use

• A draft reply contains "if you prefer", "whichever", "shall I", "want me to", "worth doing?", or any sentence whose answer is a permission.
• A review comment implies neighbouring work — more call sites, more tests, a second component — and you are deciding whether to include it.
• You are about to ask a maintainer to choose between two things you could try both of.
• You have a hypothesis about scope and are tempted to socialise it instead of measuring it.

When NOT to use

The genuine questions — the cases where asking first is right, not avoidance:

• ⭐ The answer changes what you build and is expensive to undo: a public API shape, an on-disk format, a new configuration key, which of two incompatible designs to pursue.
• The work commits you to someone else's scope — a refactor across files they own, or a ticket that is not yours to take.
• A house rule requires discussion first (a KIP, "discuss in an issue before coding"). Then asking is the work; see discuss-in-issue-first.
• The unknown is theirs, not yours: "did you intend this behaviour?" cannot be measured from outside.
• The work is large and the direction genuinely uncertain. Then ask with a measurement attached, so the question costs them one read rather than one investigation.

The practice (checklist)

• Grep the draft for permission-shaped sentences before anything else: bash grep -inE "if you prefer|whichever|shall I|should I|let me know|worth (fixing|doing)|I can (extend|add|also)|want me to|happy to" DRAFT
• For each hit, ask one question: could I answer this myself with machine time I already have? If yes, it is a request for permission to work. Delete it and do the work.
• Bound the work first, so "do it" stays cheap. Enumerate the sites before touching any: a sweep, a grep, a count. If the enumeration comes back large enough to change the PR's shape, that is a real question — and now it comes with a number.
• Look for the one change that covers many sites. Neighbouring failures usually share a cause; a guard inside a shared helper beats N copies of a guard, and it is a smaller diff to review.
• Verify each site individually AND the whole in order. Per-site green proves you fixed what you claimed; the ordered full run proves you broke nothing. Report both counts.
• Rewrite the reply as done-work: the number, what changed, the verification. Keep only the questions that survived step 2 — and state those as constraints you hit, not as choices you are handing over.

Rationalizations

RECEIPT

redis/redis#15636, 2026-08-13. A core developer reviewed a one-test fix and observed that "many tests in this file won't work with --only", offering a fork: refactor all of them, or fix the ones that bother us — then tagged a second maintainer for an opinion.

The drafted reply ended:

"@[reviewer] if the 8 above are worth fixing in this PR I can extend it to them, or keep this one narrow and do them separately — whichever you prefer."

That sentence was cut with one line of feedback: "we don't ask before we've done it ourselves and confirmed it works."

What doing it cost, in full:

• one guard inside an existing helper — setup_slot_migration_with_delay populates on the source and imports to the destination, so it structurally requires the range to be on the source. One line there covered 3 of the 8 failing tests and all 33 of its call sites.
• five one-line calls in the tests that write to the source before reaching any helper.
• total diff +47/-22, test-only, no production code.

What verifying it cost, and what it proved:

⇒ The offer would have spent a round-trip in a repo whose median outside PR waits over a month, to authorise work that took one guard, five lines, and an unattended hour. And the reply it was replaced by is shorter: a count, a three-bullet description of the change, and one genuinely open constraint that measurement could not resolve — validateImportSlotRanges requires a single owner per range, so a split range cannot be moved in one call, and no test needs that today.

⚠️ The surviving question is the shape to keep: it is stated as a limit of the implementation, with the reason, and it is not handed over as a choice.

Lifecycle

• Run the grep on every outward-facing draft — PR body, review reply, issue comment, email. Permission-shaped sentences survive prose edits because they read as manners.
• When a question survives, attach its measurement. "Should X also do Y?" plus "here is what Y would touch and what it would cost" is one read instead of one investigation.
• ⚠️ A conditional offer inside a commit message or a PR body is the same defect — it asks a reader to reply to a document. Put the finding in the text and the choice nowhere.
• Report what the extra work found even if it is dropped. The count outlives the patch; on this receipt the sweep incidentally produced the deterministic reproduction of a second open issue.