Sweep duplicates

Two issues for one bug means two people investigate it and neither sees the other's findings. The goal is one issue per underlying problem, holding everything anyone learned.

1. Search the way reporters write, not the way you think

The same bug gets filed as "export is broken", "CSV download 500s", and "can't get my data out". No shared vocabulary. Run several searches, the error string, the feature name, the user-facing verb, and pool the results rather than trusting one query.

Include closed issues. A closed one is not evidence the bug came back, triage closes far more issues than fixes do. Treat it as a regression only when the issue records a fix that shipped or was reopened; otherwise it is just another report of the same open problem.

2. Same symptom is not the same bug

Group only when the underlying cause is plausibly identical. Two issues that both say "page is slow" are the same report only if they are slow for the same reason; merging them buries whichever one nobody reproduced.

When you are unsure, link them as related and say why rather than merging. An incorrect merge loses an issue silently, and nobody goes looking for what they think is already tracked.

3. Pick the survivor deliberately

Not simply the oldest. Prefer the one with the best reproduction, then the most discussion, then the earliest. If the oldest is a one-line report and a later one has steps, logs, and three participants, the later one survives.

4. Confirm the groups before you touch anything

Show the user each group you intend to merge: the survivor, the issues folding into it, and what you will move across. Merging is destructive in the way that matters, an issue closed as a duplicate stops being found by the people watching it, and an incorrect merge is only discovered when someone re-reports the bug months later. Get an explicit go-ahead per group, or on the set if the user prefers, before the first write.