Improved search for GitHub Issues in public preview 🔍

[ebndev]

It's now easier than ever to find exactly the issue you're looking for with our improved search for GitHub Issues. Built on our new semantic index, you can now find results based on the meaning of your query not just the keywords you use.

What's new

Search for issues using natural language like "authentication failing on mobile" or "funny timeline behavior", and GitHub returns conceptually similar results, even if the issue titles or descriptions use completely different wording. The more descriptive your query, the better your results.

Our prerelease testing has found that this produces significantly better results for users. Overall, users of our semantic search find the issue they need 25% higher up the list than traditional search.

How it works

Semantic search activates when you describe what you're looking for in natural language. To make best use of this, results are now automatically ordered by "Best match" to surface the most relevant issues first.

For searches that need exact matching (e.g. queries with quotation marks) GitHub uses the traditional, lexical search engine to give you the precision you need.

During public preview, you can opt out using the feature preview dialog.

How to try it

Head to any repository's Issues tab and search using natural language.

🌟Leave a comment!

Join the discussion and leave feedback in the comments below!

Additional improvements to issues and projects

• We've fixed a bug causing slow performance when searching for labels on Edge and Safari.
• A Safari based scrolling bug impacting GitHub Issues is now fixed for smoother scroll behaviour.
• Milestone ordering works consistently for both open and closed issues.

[Aarav90-cpu]

Nice

[saadssss]

لطيف - جيد

[naankettavan0204-beep]

This is my working.and...

I

[dhirajkhavda714-svg]

Very good 5 star

[espositojoseba-ops]

من مستندات بلوكتيشن تعمل على بوادر بلوكشين من قياسات بلوك عن سياسة نيشان الكوب من نظم البوك في محاور الكتب في قياس النت من نظم المعلومات الزمنية في لوكات الوقت عن كلوك يشمل الوقت من سياسة حدت الخدمات في كوت المعامل الشين في نظم معلومات الناقل من وقته عن المستلم في إيقات الناظر عن وقت فتح الصفوح في زمن الايقاتات عن توقيت المنشور في وقت المستلمين في سياسة اللوكات عن كوادر العمل في علم المعمل في عوالم النت من الانتر عن سياسة النار في بطاريات التطبيقات من بطاريق القطوب من شمالية القطب في بطاريق الشمالية في القطب المثلج في محاور الترددات المطبقة في تطبيقات الطبق عن طريق الثلج وذلك عن شاعر مجنون من مج في فحص الملي من غرامات التقييم في الصناعات المشهورة من ترددات النت في الشبكات عن كات الشاب من كيت البنت عن قياس النواقص من نصوص القوائم الناقصة في فتح التعدين الكتابي من تاك عن بوك في مستندات التوبك عن بلوكات في اكواب الشراب عن محاور المعيشة في القط عن المثلجات المصنعة في محاور البرية في برادوي عن وديان الجبال الثلجية عن جيل من لنجات المشاركات في الطاق عن قار السيارات في طرق المسيرات المشغله عن شغله ولا تحركه في قفل كل واقف عن قافل البلوكتيشن في مستندات المعادن في فتح النظم الرقمية في جنون علمي يستند إلى علم اللغات و علم اللهجات ومحاور المفهومية الأولية في كل موقع عن كل برهان في كل أسرة عن كل مدرسة في كل منهج في كل عمر عن أعمار المتغيرات السنوية للدراسات الرقمية في مفهومية البشرية عن ذكاء القياس في كل ثقافة عن كل حضارة في محاور المخارج و المداخل عن حدود كل دولة في تعليم الدول و الحكام و الرؤساء علم المهاجرين إلى دولهم و ثقافة المهاجر و اللاجئين في تقييم الرئيس من قبل المقيمين عن حضارتهم و ثقافتهم و حفظ الله الانسان اينما وجد فهو بركة في كل بقاع الأرض .

****

Very good 5 star

• [ ]

[rap1ds]

Should the old search syntax still work?

I used to search PRs with this search syntax: label:"Pending post-merge review" OR (state:open AND label:"Pending review") which translates to this URL: https://github.com/<username>/<repository>/issues?q=label%3A%22Pending%20post-merge%20review%22%20OR%20(state%3Aopen%20label%3A%22Pending%20review%22). I think this was working just fine but some days ago this stopped working. Or do I have a mistake in the search syntax?

[alondahari]

Hi @rap1ds quick update, while not related to the release of semantic search, one of our engineers was able to replicate the issue and is investigating it. Thanks for raising it!

[jfrost-mo]

The semantic search feature is interesting, and I could see it being useful. However, currently the decision to change the default sort order of search results away from newest to the nebulous "best match" is a significant usability hindrance.

I found the search results not being ordered by newest as quite surprising, and notably less useful. In almost all cases an issue created a week ago is going to be more relevant than one created a year ago, even if the search term matches less exactly. Even when using quoting to avoid semantic search, it still uses the best match search order.

While you can change the sort order after performing the search, there is no way I've found to persist this setting.

In addition to likely being more useful, sorting by newest is much more predictable, which improves usability by ensuring the user feels in control. In a repository that the searcher is familar with, they will often be able to use the creation order of a PR to know if they need to look at newer or older issues, based on context outside of the query, such as when they remember an issue being discussed. Furthermore, if there are so many search results that the desired result is not visible on the first page, the query likely needs refinement, rather than sorting in a different order.

[dtaivpp]

@jakobleck that is a great insight! I think this is where issues, prs, and all searchables should be much more "smart". You just layed out a really clean heuristic for determining when sort order newest would be most useful. When you visit a project you've not visited before newest is a huge factor because maybe there's a new bug you're hitting.

I think there is value to adding other things to that as well. For example, lots of projects have "common bugs". Pages that get hit over and over again from Google. What do you think about those being surfaced as well? Like you mentioned often when you visit project's you've not interacted with before you are looking for a fix to an issue you're facing.

This is what I am looking to do more. I want to reduce the amount of work that people have to do when they are searching by taking advantage of what we know. When I visit a project I work on most often I am looking for thing's I am working on or am participating in with maybe the first few most recent items.

[jakobleck]

You just layed out a really clean heuristic for determining when sort order newest would be most useful. When you visit a project you've not visited before newest is a huge factor because maybe there's a new bug you're hitting.

No. Or maybe I have used the wrong word with "unfamiliar". By which I meant repos that I don't really know the codebase of too well, but it could be that I'm visiting for the first time or that I look at the issues of the repo regularly because it's a dependency I use and things tend to break on a regular basis. I think ordering by creation date is a good default no matter what.

As to "common bugs", that's a wholly different sort of topic, and I'm not sure I can give you useful insight on that.

[jfrost-mo]

@dtaivpp here are some answers to your questions. For context, I mainly work on repositories with fewer than a thousand issues.

What I would ask is what is most relevant to you as you go to the issues page?

TBH the most important is the "New Issue" button. But aside from that I am usually going to one of the most recent issues that is already at the top of the unsorted page, or searching for specific issues by their content.

Newest is nice but what happens if you're working on an issue from a while ago?

If I'm after a specific set of issues the search query usually does a good job of reducing the number of issues to just the relevant ones. If instead I want to do some actual date based work, such as when going through older issues to see what is still relevant, I'll use the explicit created:<2025-02-20 date filters (which are a lot more discoverable with the new pop up menu), as they are robust and consistent. It is this consistency that is the real draw of sort-by newest, as you know you haven't missed an issue.

Is unread more important than new that you've already triaged?

Usually not, as I have my GitHub notifications set to send emails for new issues on my repos. Therefore I read the initial issue via email, and triage via the direct link to the issue, rather than navigating through GitHub. So by the time I see an issue on GitHub I've already read it.

For a "common bugs" use case, the closes proxy that is currently available is to sort by reaction count, to see upvoted issues. The new anti-+1 banner should also help with this. It would be nice to actually get the referrer data of where people come to particular issues from, but there are enough privacy implications around collecting that data that it wouldn't be worth it. Then again, we already have the referrer information in the insights tab.

As for having the issues I'm currently assigned visible, I find that when I am looking at a repository issue tracker I usually want a more comprehensive view, including of issues I haven't touched before. The various filters at https://github.com/issues serves much better as a dashboard, and is much more discoverable now it is on the GitHub home page. The https://github.com/pulls/review-requested page is by far my most used dashboard.

Something I have been doing recently however is to remove the is:issue from the issue search, so I can see both open issues and pull requests. Often useful information ends up on both the issue and a pull request intended to fix it, and a PR might not have a corresponding issue. By showing them in one list I get a complete overview for a particular search term. I appreciate this would be far too disruptive a change to ever make default, given the split between issues and PRs is fairly core to GitHub, but I do find the distinction isn't that helpful in the common case of a single issue being fixed by a single PR.

That was a bit of a rambling set of answers, but hopefully there is something useful in there.

[GfEW]

TL;DR:
Please respect varying abilities by allowing everyone to choose defaults that work best for them:

Persistent Search Options

• sort by best match
  • on: best match
  • off: sort updated-desc
• semantic matching
  • on: semantic matching
  • off: strict matching
• smart input
  • on: aided typing
  • off: verbatim typing

Full Story:

@dtaivpp

we're starting to look into how do we reduce the amount of work you have do to when you land on a page

In order for "smart" changes to reduce the amount of work associated with landing on a page, the underlying model of "work" obviously needs to reflect users' perceived "workload" attributed to the constituents of interaction.

The weighted distribution of perceived workload varies with personal abilities, preferences, and workflows based thereon, much more than could reasonably be optimized in a "one size fits all" approach.

Users whose main interaction bottleneck is visual parsing bandwidth(1) frequently find themselves on the losing side of optimizations that aim at reducing the "physical" workload for the majority (think of benign routine keystrokes, e. g. closing quotes) at the cost of an ever-increasing need to visually track what's happening or being suggested. (2)

Even if traditional interaction is surely lacking the fancy bit, users whose efficiency sweet spot depends on

• plain chronological order
• strict, reliable matching, and
• predictable, unaltered results of typed input

shouldn't be force-fed ways of interaction that, regardless of their "smart" label, perpetually require a multiple of the visual recognition and adaptation workloads required in traditional interaction.

Thanks for considering!

(1)

like myself

(2)

In that regard, search filter completions are actually a net positive example, precisely because they do not alter "blindly" typed keyboard input, and rather leave it up to the user to utilize them when desired.

[fm-sys]

Exactly. I believe there are different user stories:

• As a user, I want to quickly find whether a feature request / bug report have already been reported (=> best semantic match)
• As a maintainer, I want to see which bugs have been coming in lately. "there was this thing about xyz a few days ago" (=> newest-first / last updated first)
• As a product owner, I want to see which open issues generate the most traffic (=> most reactions / comments)

[amenity]

It would be so helpful to have this functionality in GitHub Projects—at least boolean operators. 🙏🏻 🙂

[Utumno]

Hi - would be really nice if one could select issues and apply actions as in milestones view (ex. https://github.com/wrye-bash/wrye-bash/milestone/19) in the search view (ex. https://github.com/wrye-bash/wrye-bash/issues?q=%20label%3AA-scripts)

[therealPaulPlay]

Just wanted to chime in and say that it's been working quite well for me. Finds a bunch of issues about the same problem, even if they don't include the words from the search query.

[MagaKaStoporom]

what is this

[ktauchathuranga]

what if we can see the labels even when it pinned...

[janicegrech1-hash]

great things ahead

[NicolasGorga]

Hey this is amazing. When will it be available through the API? This would prove beneficial to any agent needing to go through issues

[espositojoseba-ops]

Pues en cuanto acabe porque estoy intentando hacer unas cosas y hago una cosa pero no me gusta prefiero hacer otra porque quiero hacer una cosa diferente a los demás y la parte que hay días que no puedo me digas porque estoy en el hospital ingresado porque me pasa mucho tiempo ingresado porque tengo cáncer y más cosas y estoy pues a ratos en cuanto pueda el otro que ha hecho pues lo haré yo tengo mis 16 códigos tengo mi licencia de desarrollador tengo en telegram también eh todas las licencias de desarrollador tengo todo a mí nadie me puede decir nada o sea yo te tiras a decirme algo que vos oye pues si tengo que hacer lo que tengo que hacer y la justicia o lo que sea pues le vale El vie, 27 mar 2026, 18:25, Nicolas Gorga ***@***.***> escribió:

…

Hey this is amazing. When will it be available through the API? This would prove beneficial to any agent needing to go through issues — Reply to this email directly, view it on GitHub <#185760?email_source=notifications&email_token=BVQ5EWMZK74MEYQ2H77DVYL4S22PTA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTGQ3TONZXUZZGKYLTN5XKOY3PNVWWK3TUUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16347777>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BVQ5EWPY7ZGKHMMH6CIOKC34S22PTAVCNFSM6AAAAACTB4G3LCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZUG43TONY> . You are receiving this because you commented.Message ID: ***@***.***>

[Kidsrule6]

¡Espero que te mejores pronto! Siento que te hayas enfermado.

[espositojoseba-ops]

El código ya está corregido está perfecto

[espositojoseba-ops]

Muchas gracias compañero ya llevo 11 años así