Ship something to a few thousand users and the first thing you learn is that bug reports do not arrive one per bug.
A single broken checkout produces forty reports over an afternoon. Handled naively, that is forty items to read, forty to categorize, and thirty-nine to close as duplicates. The busiest day of your bug tracker produces the least information.
Reports and tasks are different things
BugDump keeps them separate, and this is the structural decision everything else rests on.
A report is one submission from one user at one moment — their description plus everything the SDK captured. Reports are immutable evidence. They are never edited, never merged, never deduplicated.
A task is the thing you fix. It has a public ID, a column on the board, comments, and an activity history.
Many reports attach to one task. Forty reports about checkout become one task with forty pieces of evidence.
The distinction is not bookkeeping. It reflects something true: the evidence and the work are different objects with different lifecycles. Evidence accumulates and never changes. Work moves through states and eventually ends. Systems that conflate them force you to pick one — either you lose evidence by merging duplicates, or you drown in items because every piece of evidence is also a task.
Duplicates are an asset
Once reports attach to tasks, duplicates stop being noise. They become your best debugging signal.
Forty reports on one task give you something no single report can: the intersection.
If all forty are Safari, it is a Safari bug — and you knew that before opening a debugger. If they span every browser but share a viewport under 768px, it is responsive. If they cluster in a fifteen-minute window and then stop, it was a deploy, and you should be looking at what shipped rather than at your code.
That analysis takes seconds when reports are grouped and is nearly impossible when they are forty separate items in a list. The most common shape of a real incident — many people hitting one thing — is exactly the shape a flat inbox handles worst.
This is also where the MCP server earns its place. "Read the reports on #17 and tell me which browsers are affected" is a question an agent answers in seconds by reading all forty. Cross-report comparison is tedious enough that humans skip it, which is why it is worth automating.
The board
Tasks live on a kanban board with columns you define. Each column maps to one of two states: open or closed.
The mapping is what matters, not the label. You might run:
Triage → Confirmed → In Progress → Done → Won't Fix
Where the first three are open and the last two are closed. Or you might run something entirely different — the two-state model means the system understands what counts as outstanding regardless of what you call your columns.
Two states, not five. Every "Deferred / Blocked / Needs Info / Waiting on Customer" taxonomy we have seen ends the same way: a column that fills with tasks nobody looks at again. If a task is not done it is open, and open work should be visible.
Won't Fix mapping to closed is deliberate too. Deciding not to fix something is a real resolution. It should leave your open queue.
A triage loop that works
Read the new reports, group them. Most are duplicates. Attach them to existing tasks. This is the highest-leverage ten minutes of the process — forty items become six.
Create tasks for what's genuinely new. One per distinct bug.
Use the intersection. For any task with multiple reports, look at what they share before you look at code.
Move it, don't annotate it. Position on the board is the status. A task in In Progress with a comment saying "actually blocked" is a task in the wrong column.
Close things. Including the ones you won't fix.
Closing the loop
Each project can publish a public portal at your-project.bugdump.com where reporters follow the tasks they filed.
This is the part most tools skip, and it is the part that determines whether you keep getting reports.
A user who reports a bug and hears nothing concludes that reporting does nothing. They are making a rational inference from the evidence available. Next time something breaks, they work around it silently — and you lose the signal.
A user who watches their task move from Confirmed to Done has learned the opposite lesson. They report the next one, and the one after that.
You can also let reporters attach to a task themselves. With allowTaskAttach enabled, someone who knows a task's public ID files their report directly against it. For internal QA and beta groups who already track your task IDs, that skips your triage step entirely — reporters group their own duplicates.
The short version
Reports are evidence. Tasks are work. Keep them separate, let duplicates accumulate as evidence rather than fighting them, keep the board to two real states, and show reporters what happened.
Forty reports become six bugs, and the six arrive with better evidence than any single report could carry.