01 Overview
Duplicate bug reports are not a failure of the reporting process. They are a natural consequence of many people observing the same underlying defect from different angles, at different times, with different context. A tester running a regression pass may file a crash that a support engineer already reported from a customer screenshot two days earlier. A developer may notice a flaky assertion in a log that a product manager described as a vague visual glitch. The reports look different because the observers are different, but the root cause is often the same. Treating duplicates as noise wastes the information they carry.
The craft problem is not how to prevent duplicates. It is how to merge them without erasing the original report. The original report holds the first reproducible evidence, the initial severity call, and the conversation that followed. When you close it as a duplicate of a newer report, you discard that history and create a confusing trail for anyone who later searches for the issue. The better practice is to keep the original report as the canonical record whenever it is the most complete, and to link later reports to it as supporting evidence. This article is about making that decision consistently during triage, so that deduplication strengthens the record instead of thinning it.
Good deduplication is a routing skill, not a cleanup chore. It requires reading each report for its claim, not just its title, and comparing the underlying failure rather than the surface symptoms. When done well, it reduces duplicate work for engineers, preserves the reporter's contribution, and gives future readers a single place to find the full story.
02 What the report is actually claiming
Before you can decide whether two reports describe the same defect, you have to state what each one claims. A bug report is an argument: under these conditions, this behavior occurs, and that behavior is wrong. The claim has three parts: the trigger, the observed result, and the expectation that makes the result a defect. Two reports are duplicates only if they share the same underlying trigger and the same underlying failure, even if the words, screenshots, or affected surfaces differ. A report titled with a symptom is not a claim until you can restate it in those terms.
Consider a report that says the save button does nothing. Another says the document is lost after refresh. These may be the same defect if the save action silently fails and the refresh reveals the loss. They may also be different if the first is a UI feedback problem and the second is a persistence problem. The only way to know is to read the repro steps and the expected behavior, then ask whether fixing one would fix the other. If the answer is yes, they belong together. If the answer is maybe, they are not yet duplicates; they are related reports that need more evidence before merging.
This restatement habit also protects you from false merges. A crash on startup and a crash on shutdown are not the same defect just because both are crashes. A slow query and a slow render are not the same defect just because both are slow. The claim, not the category, is the unit of deduplication. When you write the claim in plain language, you make the merge decision auditable and reversible.
03 Severity versus priority
Severity describes how much damage a defect causes. Priority describes when the team intends to fix it. These are separate judgments, and conflating them is one of the most common sources of duplicate confusion. A defect can be high severity and low priority, such as a crash that only occurs in a deprecated configuration no customer uses. It can be low severity and high priority, such as a typo on the checkout page that damages trust during a launch. When two reports describe the same defect but assign different severity, that is not a contradiction; it is a signal that the reporters had different contexts. The triage decision should reconcile the contexts, not average the numbers.
Priority is a scheduling decision, and scheduling depends on more than damage. It depends on how many users are affected, whether a workaround exists, whether the fix is risky, and what else is competing for the same release. A duplicate report that arrives with a higher severity rating is valuable because it may reveal a population or scenario the original reporter did not consider. Instead of closing it, link it and note the new context. The original report keeps its severity, and the team gains a fuller picture for the priority call.
Keeping severity and priority distinct also helps when a defect comes back. If a fix was prioritized low because the damage seemed contained, and the defect reappears in a broader surface, the severity assessment was wrong, not the priority process. Recording both fields separately lets you learn from that. A merged report with clear severity and priority notes becomes a small case study in how the team reasons about risk.
04 Writing steps someone else can follow
The repro steps are the part of a report most likely to be lost or degraded during deduplication. When you merge a later report into an earlier one, you must preserve any step that makes the failure easier to trigger. The standard is simple: another person, with no prior context, should be able to follow the steps and see the defect without asking a question. That means starting from a known state, naming the exact inputs, and describing what to look for. Vague steps like try saving a few times are not steps; they are hopes.
Good steps are minimal but complete. Minimal means you remove anything that does not affect the outcome, so the reader does not waste time on irrelevant setup. Complete means you include the conditions that do affect the outcome, such as the account type, the data shape, the browser or device, and the order of operations. If the defect only appears after a specific sequence, that sequence is the report. If it appears intermittently, say so and describe the observed frequency in plain terms without inventing a rate. Intermittent defects need more attempts, not more adjectives.
When merging duplicates, compare the steps side by side. If one report has shorter steps that still reproduce, keep those as the canonical steps and note the longer version as an alternative path. If one report has steps that reproduce more reliably, keep those. The goal is not to preserve every word but to preserve every condition that matters. A merged report with clear, testable steps is worth more than two reports with partial ones, because it lets the next person verify the fix without redoing the discovery work.
05 Running the triage queue
Triage is a routing review, not a debate about whether the defect is real. The queue exists to confirm, classify, and assign reports so that work can proceed. When you encounter a possible duplicate, the first question is whether the underlying claim matches an existing report. If it does, you link the new report to the existing one and record the relationship. If it does not, you treat it as a new report and move it forward. The decision should take minutes, not hours, because the queue is a throughput problem as much as a quality problem.
A useful triage habit is to search by claim, not by title. Titles are written for humans in a hurry and often describe the symptom rather than the cause. Search for the trigger and the failure together, and look at reports that were closed recently as well as those still open. If you find a match, read the original report's status and affected area before linking. A report that was closed as fixed is not a duplicate of a new report unless the new report shows the same defect returning; in that case, the relationship is a regression, not a duplicate. Naming that relationship correctly keeps the history honest.
When you link reports, leave a short note explaining why they are considered the same. The note should restate the shared claim in one sentence and mention any new context the duplicate adds. This note is for the next reader, who may need to reopen the decision. It also protects the original reporter, whose work remains the canonical record. A triage queue that links duplicates with clear notes becomes a searchable knowledge base instead of a graveyard of closed tickets.
06 When a defect comes back
A defect that returns after being marked resolved is not a duplicate of the original report. It is a new event with a relationship to the old one. The distinction matters because the fix may have been incomplete, the environment may have changed, or the original diagnosis may have been wrong. Treating the return as a duplicate would hide that signal. Instead, reopen the original report if the same claim still holds, or file a new report and link it as a regression. Either way, the history should show that the defect was believed fixed and then observed again.
When you reopen, preserve the original repro steps and add the new evidence. Note what changed since the fix, such as a new release, a configuration change, or a different data set. If the return happens in a different affected area, say so; the fix may have addressed one surface while leaving another exposed. This is where severity and priority may need to be revisited. A defect that was low severity because it was contained may now be higher severity if it has spread. A defect that was low priority may now deserve attention if it undermines confidence in a recent release.
The hardest case is the intermittent return, where the defect appears once and then cannot be reproduced. Do not close it as a duplicate or as fixed. Leave it open or in a needs-investigation status, and record the conditions of the sighting. The value of the ledger is that it remembers what the team observed, even when the team cannot yet explain it. A defect that comes back is a prompt to re-examine the claim, not a reason to erase it.
07 Frequently asked questions
How do I know two reports are truly duplicates? Restate each report as a claim with a trigger, an observed result, and an expectation. If fixing one would fix the other, they are duplicates. If the relationship is uncertain, link them as related and gather more evidence before merging. The cost of a false merge is higher than the cost of a temporary link, because a false merge hides information while a link preserves it.
Should the newer report ever become the canonical one? Yes, when it is more complete. If the newer report has clearer repro steps, a better severity assessment, or additional context that changes the claim, it may deserve to be the primary record. The rule is not first in wins; it is best evidence wins. When you switch, link the older report to the newer one and note why, so the history remains traceable.
What do I do with a duplicate that contains a unique detail? Keep the detail. Link the report and copy the unique condition into the canonical report as a note or an additional repro path. Deduplication should reduce redundant work, not discard observations. A detail that seems minor today may explain the defect tomorrow.
How should I handle duplicates across different affected areas? Treat them as related until you can show the same underlying cause. Different surfaces often mean different owners and different fixes. If the cause is shared, link them and note the shared claim; if not, keep them separate. The affected area is a routing signal, not a merge criterion by itself.