Detecting Duplicate Issues - Public Preview

[sunnyi101]

duplicate.detection.mp4

If you maintain a repo with more than a handful of issues, you know duplicates are a time sink. The same bug gets reported three different ways, you close the duplicate, link to the original, and repeat. For high-volume repos this adds up to hours of triage every week.

Duplicate detection is now available in public preview. When you're creating an issue, GitHub checks for potential duplicates as you type and surfaces them inline before you submit. No extra steps, no workflow changes. You see suggestions, you decide what to do with them.

How it works

As you fill out a new issue, once the title is complete and the body reaches 100 characters, we search for existing issues that look similar. If we find potential matches, up to three suggestions appear right in the issue form.

• Results are based on meaning, not just keyword matching
• Works in both the full-page and modal issue creation views
• Suggestions are non-blocking. You can always submit your issue regardless of what's shown

The goal is simple: catch duplicates at the point of creation, before they become triage work.

⏱️ When it triggers

Duplicate detection triggers when:

1. The issue title is filled out (at least 20 characters)
2. The issue body reaches 100 characters

We chose these thresholds to balance two things: giving enough signal to return good results, and showing suggestions early enough that you haven't already committed to submitting.

Once triggered, title edits will re-run the search. Body edits after the initial check won't re-trigger (to avoid distracting you while you're writing).

💬 Feedback

We're actively iterating on this and your input directly shapes what comes next. We'd love to hear:

1. Are the suggested duplicates relevant, or is it surfacing noise?
2. Does the timing feel right? Does it show up too early or too late in your writing flow?
3. Does the UI feel unobtrusive, or does it get in the way?

Share feedback, report issues, or suggest ideas in this discussion.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[maheerCodes]

hey @sunnyi101 👋 .
this is a really useful addition ,,,duplicate triage is genuinely one of the more tedious parts of maintaining any active repo.

feedback after trying it out :

whats working well :

• the semantic matching is noticeably better than simple keyword search ,,,it caught a near-duplicate where the wording was completely different but the underlying issue was the same.
• non-blocking is the right call,,, suggestions that force you to stop and acknowledge them would get dismisssed immediately out of habit.

a couple things worth considering:

• the 100 character body threshold feels slightly high,,,,some issues are naturally short and descriptive (especially bug reports with a clear one-liner reproduction step). might be worth testing a lower threshold or making it title-only for short issues.
• would be helpful to seee a confidence score or similarity indicator next to each suggestion,, right now its hard to tell if the match is 95% similar or 40% similar ,that context helps decide whether to check it or ignore it,
• body edits not re-triggering makes sense for UX,,,but maybe a manual "re-check" button after finishing the body would be a nice addition for longer issues where the topicc shifts mid-write .

overall though ,the timing and placement feel right,,,,,,,it shows up early enough to be useful without being intrusive.

good feature 💙💙💙💙.

[sunnyi101]

Thanks for the feedback! Really helpful to hear what's working and what's not.

On thresholds - we've been thinking about lowering to title-only triggering. It makes sense for shorter issues. The tradeoff we're navigating is precision vs false positives - we want suggestions to be genuinely useful, not noisy. More signal (body text) helps with that, but we hear you that some issues are short and descriptive enough without a long body.

Confidence scores and a manual re-check button are both on our minds. Appreciate the ideas - keep them coming.

[krassowski]

I love it. It's amazing. Thank you.

One small concern: can the word limit and semantic matching filter out issue templates, or could we have a control over which fields of an issue template get used for semantic search (e.g. description but not a dump of debug logs/package versions)? These are irrelevant for the most part and I can see how they could skew results.

[sunnyi101]

Thanks for the feedback! Glad it's working well for you.

On template boilerplate - this shouldn't be an issue because we don't capture any HTML in the semantic search. The matching is based on the user-written content (title + body text), so template scaffolding like debug log sections or version dumps rendered from HTML templates won't skew the results. If you're seeing noisy matches though, let us know and we can dig in.

[ViktorRindom]

This is an awesome feature but i would personally like a shorter title trigger (or an option to configure in a setting) because most of the time in my issues either,
the title is shorter than 20 and has a detailed body text,
or the title is long enough to cover the issue with practically no body. (I work in a small team and often write issues to myself)

I had not realized this feature was in preview before i saw this post. I get that the results will be better if there is more text but sometimes its just about 2 people not creating the same issue after a talk/meeting.

btw I'm not against having 20 and 100 as defaults but settings would be nice.

[sunnyi101]

Thanks for the feedback! Lowering to title-only triggering makes sense - especially for small teams where issues are direct and to the point.

We're working on finding the right balance between precision and false positives. A shorter trigger means more chances to surface duplicates, but also more risk of noisy suggestions. That said, your use case (two people creating the same issue after a meeting) is exactly the kind of thing we want to catch, so we're exploring how to make that work without sacrificing result quality.

[ViktorRindom]

Maybe just a button where i can force it to run the check now? that way you can focus the default values to trigger on the best result and then i can force it to run when I'm "done" writing the issue if i want a check. sometimes as the issue writer i know that it might be a duplicate

[doudou0720]

In some language ,it's quite difficult to reach 20 in the title. I think. :(