Duplicate Bug Reports Are Data, and Merging Them Throws It Away

The second report of a bug you already have gets closed as a duplicate, and that is usually correct bookkeeping and occasionally an expensive mistake.

It is a mistake because of what the second report contains that the first does not. Two people hit the same failure from different machines, different accounts, different networks and at different times. The bug is the thing they have in common. Everything else about them is the variation, and the variation is how you find it.

Close the duplicate without reading it and you have kept the sentence and discarded the experiment.

What a second report tells you that a first one cannot

One report gives you a description. Two give you a comparison, and comparisons are what diagnosis is made of.

It is not one person’s setup. The single most common way an investigation stalls is the quiet suspicion that the reporter has something odd on their machine. A second, unrelated person removes that suspicion in one line, and removes it much more convincingly than the first reporter insisting they have cleared their cache.

The intersection narrows it. If both are on Safari and everything else about them differs, you have a browser bug. If both are on the same account tier and nothing else matches, you have a permissions or plan bug. The shared attribute is the suspect list, and it takes two reports to have one at all.

The difference narrows it too, from the other side. If one is on Windows and one on Android, the operating system is exonerated. Every axis on which two reports differ is an axis you can stop investigating, which is usually worth more than the axis they share.

Timing tells you whether it is spreading. Two reports an hour apart after a deploy is a live incident. Two reports three weeks apart is a long-standing edge case nobody hit. Identical symptom, completely different response, and you cannot tell which you have from one report.

Weak

Closed as duplicate of #4412.

Better

Duplicate of #4412. Both on Safari, different accounts, different countries, both after Tuesday's release. Safari-only and started with that deploy. Details added to #4412.

What to do instead, which costs about a minute

You still close it. The tracker should not carry two open tickets for one bug, and nobody is arguing for that.

The thing to change is the order. Read it, take what it adds, put that on the original, then close it pointing at the original. In practice that means copying across four things:

• The environment, even when it matches, because a match is itself a finding.
• The timestamp, which turns two reports into a frequency.
• Anything the first report did not have: a console error, a URL with different parameters, a step the first reporter did not mention taking.
• The fact that there are now two, which is the part most often lost, because a ticket that says “reported twice, independently” is triaged differently from one that does not.

The counting problem underneath

There is a second cost, and it is slower to notice.

Duplicates are the only signal most teams have about how often a bug actually happens. Severity is a judgement about how bad one occurrence is; frequency is a fact about how many there are. A tracker that merges duplicates without counting them keeps the judgement and discards the fact, and then prioritises on the half it kept.

This is how a bug that eleven people reported ends up below one that somebody influential reported once. Not through bad faith. Through a merge policy that treated the eleventh report as administrative noise.

If your tracker can count duplicates, count them. If it cannot, a line on the original saying “reported by 11 people between 3 and 27 September” does the same job and survives being read by somebody who was not there.

What to take from it

A duplicate is a second measurement of the same event, and the second measurement is where the useful information is, because the first one had nothing to be compared with.

Close them, but read them first and carry what they add. And keep the count, because how often something happens is a fact your tracker is otherwise not recording anywhere, and it is half of every prioritisation decision you make.