file-issue

# File an issue worth picking up An issue is a handoff to someone who was not in this conversation. The test is whether they can start without asking you a question. ## 1. Search before you create Search for the error text and for the feature name separately — people describe the same bug in words that share no vocabulary. Check closed issues too, but do not read "closed" as "regression": most closed duplicates were closed during triage, not fixed. Call it a regression only when the issue shows a fix that shipped, or it was reopened — then it is a more urgent and differently-shaped report than a new bug. Found a duplicate? Comment the new evidence on it instead of opening a second issue. Show the user the duplicate you matched and the comment you intend to leave, and post it only once they say to. A wrong match buries a real bug under an unrelated issue, and nobody goes looking for what they think is already tracked. ## 2. Establish what actually happens The report you were handed is a symptom filtered through someone's theory of the cause. Separate the two. Write down what was observed, and mark anything you inferred as inferred. Where you can check the claim, check it. An issue that says "search is broken" and an issue that says "search returns no results for queries with an apostrophe, verified on staging" have very different lifespans. ## 3. Write the body in the order it gets read 1. **What happens** — one sentence, observable, no diagnosis. 2. **Steps** — numbe...