discuss-in-issue-firstlisted

# Discuss in the issue first (to move faster) ## Purpose Prior discussion on the tracking issue means the PR lands into pre-built consensus: the community already agreed the change matters and roughly how it should look, so review is cheaper and faster. The honest, measured claim is about **speed, not acceptance** — issue-first PRs merge markedly faster, but they do not merge at a higher *rate*. So the reason to do it is to shorten time-to-merge and avoid a rewrite after a cold PR meets a design objection, not to improve your odds of getting in at all. Calibration matters here: do NOT sell this as "gets accepted more often" (the data refutes that), and do NOT pair it with a "minimize review cycles" rule — in the same corpus, *more* review comments correlated with a *higher* merge rate, so cycles are a sign of engagement that lands, not of doom. ## When to use - Before opening a PR for any non-trivial change (behavior change, new API, refactor, anything with a design decision). - Skip for genuinely trivial changes — typos, broken links, mechanical dep-bumps. ## When NOT to use The change is genuinely trivial (typo, broken link, mechanical dep-bump) — the discussion overhead then costs more time than it saves. ## The practice (checklist) - [ ] Find or open the tracking issue for the change. - [ ] State the problem and your proposed approach on the issue; surface the design question rather than presenting a finished PR as a fait accompli. - [ ] Get a maintainer'