How do you stop a bug-bash capture channel from filling with duplicate reports?

## Why duplicates are structural, not sloppiness Put twenty-three people on one build and they will not distribute themselves evenly over the defect population. Defects differ enormously in how easy they are to trip: a broken date format on the busiest screen will be found by nine people in the first ten minutes, while a permission edge on a rarely used reconciliation report is found by nobody unless someone is sent there. So the arrival curve of a bug bash is front-loaded and lumpy, and duplicates are the arithmetic consequence of the format rather than evidence that participants were careless. That framing matters because it tells you where to spend effort: reduce the *cost* of duplicates, and prevent the avoidable ones, rather than lecturing participants. ## A worked shape Take a warehouse stock ledger, a **94-minute** window, twenty-three participants across nine areas. A realistic pile looks like this: 133 raw reports arrive; after merging, 71 are distinct; 22 of those were already open before the event; 12 turn out to be one intermittent save timeout in the shared environment reported under a dozen different titles; the rest are new. Read the numbers and the costs are obvious. The 22 already-open ones were fully preventable with a published known-issues list. The 12 timeout reports were preventable with a smoke pass and one announcement. The remaining duplicates — the same date-format defect from five different areas — are the irreducible tax. Sorting the pile cold, days later, means reading 133 items with no reporter to ask; sorting it live means most merges happen in seconds while the two reporters are both present. ## The three points of intervention **Before.** Publish known issues in the channel and in the briefing, including anything the smoke pass turned up. State the areas and who has each, so a participant seeing something outside their area knows whose it is. **During.** Fix the title shape — area tag, screen or object, what went wrong, in that order — because a consistent prefix is what makes scanning and text search work. Keep the running list visible: a channel where each report is one message, or a board that the watcher updates. Ask participants to scan the last few minutes of the channel before filing anything on a busy screen. Keep the capture bar low: the point during the window is to record the observation, not to work it up. **Live merging.** Staff one person as duplicate-watcher who does not hunt. Their job is to read every incoming report, merge the obvious repeats immediately, ask the one clarifying question that makes a vague report usable, and watch the area distribution — when six reports come from receiving and none from transfers, they say so in the channel and someone moves. The watcher role is also the natural home for spotting an environment-wide fault early: they are the only person who sees the whole stream. ## Titles and normalisation A consistent title shape produces a cheap grouping key. If reports look like `[adjustments] save spinner never ends on quantity change`, then lowercasing, stripping the tag and matching on a few distinctive words groups most repeats mechanically, leaving the watcher to judge the ambiguous ones. This is a helper, not a replacement for a human: two reports of the same underlying fault often describe two different symptoms, and only a person notices that the frozen spinner and the duplicated ledger row are the same timeout. ## What not to do Do not make the filing form long in the hope of getting cleaner reports. A heavy form during a time-boxed hunt suppresses reporting — participants who are visitors will simply not bother — and you lose observations, which is a worse trade than absorbing some duplicates. Do not ask participants to search an issue tracker before filing, either; searching is slow and they do not know the vocabulary the tracker uses. Do not rank participants by report count: it directly incentivises volume and re-reporting. Also resist finishing the sort during the window. The temptation is to have the watcher fully work up each finding as it arrives; that turns one person into a bottleneck and stalls the stream. Capture broadly now, work items up afterwards, with a named owner and booked time. ## Judging afterwards The honest measures of a bug bash are the distinct count after merging, how many of those were in areas the designed suite claims to cover, and how many turn out to matter once someone looks properly. A pile of 133 reports that collapses to 71 distinct, of which 22 were already known, is a normal and healthy outcome — reporting the 133 as the result of the event is the mistake, because it flatters the event and misleads whoever reads the summary.