GitHub Issue Duplicate Detector

[01x4-dev]

🔍 Search Terms

"duplicate"

✅ Viability Checklist

• [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [X] This wouldn't change the runtime behavior of existing JavaScript code
• [X] This could be implemented without emitting different JS based on the types of the expressions
• [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• [X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

As there are lots of open issues (5k+ when writing this), the likelihood for the community of inadvertently introducing new duplicates is fairly high.

The only way for contributors to mitigate this risk is to follow the recommended guidelines and rigorously searching (manually) similar issues prior to open a new one.

Needless to say, this is error prone as it depends on the quality of the research itself.
Result: while everybody agrees on the rulebook, life is too short so let's submit new issue right away... 🤷🏻‍♂️

The new GitHub action ghidd delivers a seamless repo maintainer experience aiming to simplify triage tasks by automatically spotting and tagging duplicate issues.

📑 Read more at https://github.com/marketplace/actions/github-issue-duplicate-detector Contributions are highly welcome 🙏🏻

📃 Motivating Example

This is a feature purely for repo maintainers, translating to a smoother community experience (e.g. less friction when contributing)

💻 Use Cases

1. What do you want to use this for? To let repo maintainers simplify their triage tasks by automatically spotting and tagging duplicate issues
2. What shortcomings exist with current approaches? More time consuming and error prone results. More tedious contributor experience. Less accurate results leading to higher duplicate missed = tech debt and issue backlog rapidly increasing at scale.
3. What workarounds are you using in the meantime? Rely solely on contributors to religiously follow your guidelines and make their research prior to submit a new issue...good luck with it 😉

[RyanCavanaugh]

I read the code of the repo and this is not production ready. I don't think you've tried it on something with 5,000 open issues, let alone the 30,000 closed ones (duping to closed issues happens all the time). It's not scalable solution to live-fetch every single issue and re-ping GPT on each one hoping to find a duplicate.

[01x4-dev]

Thanks for the helpful comments, @RyanCavanaugh - duly noted ✌🏻 Closed issues should be out of context as GitHub API used only returns open issues. Nonetheless I agree the live-fetch should be improved. ghidd is still at early stage indeed, but I'm already working to support caching during the first all pass to learn the installed open issue base and avoid re-pinging GPT during new mode. Should help to speed up traversing list of open issues while saving tokens / cost.