do-the-work-before-you-offer-itlisted

# 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 p