Duplicate feature requests split context across several discussions. They also tell you that people use different words for the same problem. The goal is to make the evidence easier to follow while preserving meaningful differences, rather than deleting every title that looks similar.
Start by comparing the task and desired result. Two requests mentioning “export” may be duplicates, or one may concern a one-off client report while the other concerns a recurring backup. Similar labels are a reason to investigate, not proof that the needs are identical.
Read the problem before matching titles
Check the request description, comments, and any recorded source. What was the person trying to do? What prevented it? What workaround exists? If those answers differ, keep the distinction visible. A single broad request can become so vague that it is no longer useful for a decision.
Consider a hypothetical pair: “Download a weekly report” and “Export all my data before leaving.” Both mention downloads, but one is a sharing task and the other is portability. Combining them without explanation would obscure the intended outcome and could lead to the wrong scope.
Choose a main discussion for a reason
When requests describe the same problem, choose the discussion with the clearest context or the established owner response. Do not choose only by the largest count. Record why the discussions belong together and point contributors to the place where future clarification should happen.
If your tool offers a merge operation, check its actual behavior before using it. Does it preserve comments, source context, and vote identity? Do not manually add vote totals and call the result unique users. The same person or installation may have participated in both discussions.
Preserve useful differences
Write a short summary of any extra constraints before linking a duplicate. For example: “This discussion adds an offline requirement to the same weekly reporting problem.” Keep a reference to the original discussion so an owner can revisit the source if the distinction becomes important.
Do not copy private support details into a public summary. Preserve the product problem while removing account records and personal information. If a participant needs individual help, keep that support conversation separate from the public request. Read choosing a feedback channel for that handoff.
Tell contributors where to respond
A closure note should explain what happened and provide a clear destination. “This describes the same reporting task as the linked request. Please add any additional constraints there” is more helpful than “Duplicate.” People should be able to see that their input was considered.
If the destination's scope does not match a participant's experience, invite them to explain the difference. That response may show that the original match was wrong. Treat the grouping as a decision you can revise, not a permanent judgment about the person submitting feedback.
Review the board periodically
During a regular review, look for repeated task descriptions and requests with missing context. Improve titles so users can find an existing discussion before submitting. Use a comment to ask one clarifying question instead of immediately making a larger commitment.
This is a suggested moderation workflow, not a claim that VoteWant automatically merges requests or transfers every interaction. Current public reads and owner automation are described in VoteWant's API documentation. Explore VoteWant for the current board experience, and read writing useful requests to make future duplicates easier to recognize.