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

[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.

[jakobleck]

I'm with @jfrost-mo : Ordering by creation date, i.e. showing newest issues first, should be the default behaviour. It's consistent.

Importantly: Search results are never going to be perfect. You have to go through them by hand anyway. And when you are using a certain version of a program/package or your issue occured at a certain point in time, you approximately know where to look and where to stop looking in the timeline. This is what makes ordering by date as default useful, and IMHO this is a frequent usecase. (For me this applies to unfamiliar repos.)

[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.

[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.

[olansadiwa47-lang]

Release

[josejp7]

Pueden hacer que los cheats por ejemplo de PSP funcionen permanentemente es decir que se estén sobreescribiendo cada segundo ya que después de una cinemática de un juego se desactivan y hay que volverlos a poner manualmente

[PLASMAchicken]

Why do I need to put " " to find the text littearlly in the title ....

[joshuajbouw]

Is this available in the CLI by chance or just in the web UI?

[alondahari]

It's currently available only through the web UI, we are exploring ways to make it available on more surfaces

[joshuajbouw]

Thanks for the reply, this is really exciting to see that this will likely come to the CLI!

[resistdesign]

I want to be able to set the number of items per page to something higher than what's there.

[alondahari]

You can pageSize as a query param in the url: https://github.com/microsoft/vscode/issues?pageSize=100

[denisefrye]

Well I guess y'all are helping him hack my account .

[mizaanbhaai-ui]

Thanks oll শনি, ২৮ ফেব, ২০২৬ ৪:৩৭ PM তারিখে Andrés ***@***.***> লিখেছেন:

…

https://www.govinfo.gov/app/details/CFR-2025-title2-vol1 — Reply to this email directly, view it on GitHub <#185760 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B5S7WTHZ3KVRAZALH73UUTL4OFVWBAVCNFSM6AAAAACTB4G3LCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJVGQZDOOI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[ivanperez-keera]

Please stop trying to guess what I mean in my searches. I know what I mean. I'll type what I mean.

Google does this and it's extraordinarily frustrating. Don't be like Google.

[GfEW]

Please stop trying to guess what I mean in my searches. I know what I mean. I'll type what I mean.

Google does this and it's extraordinarily frustrating. Don't be like Google.

Nicely put. I couldn't agree more.

Same goes for typing - don't mess with how key presses translate to input characters.

If suggestions are made and the user accepts, that's fine, but don't alter typed input by auto-inserting anything.

[jakobleck]

Overall, users of our semantic search find the issue they need 25% higher up the list than traditional search.

What kind of a metric is that anyway? (A successful search result is a diffuse concept, I would say, there can be multiple matching results or related topics/partial matches; also, success can mean to no find a result for the given query (and this is where some sort of reliability is key that natural language seemingly search cannot offer). It's not always "the issue you need".) If the average position of the successful result already was 4 with the standard search, that's extremely good. And if you over-optimize this to a value around 3 by sacrificing reliability, how does this affect the time to reach the successful result or the number of attempts (submitting the search)?

Also, over what kind of searches are you averaging to judge performance? A frequent usecase (for me this could be well >25% of my github usage) is to search for (parts of) an error message to see related issues. Typing quotes each time instead of just Cmd+V and Enter is inconvenient. But probably necessary in the current state. We are in programming. Exact matches matter (more or less, modulo case sensitivity etc.). If I go to https://github.com/flutter-webrtc/flutter-webrtc and search for webrtc-sdk (the name of a dependency of that package), I am looking for issues containing the name of that dependency, and natural language search results are useless.

P.S.: What is displayed in the abscissa in the graph in the first post? :D

P.P.S.: What I mean by "reliability" of the search, I'm not 100% certain myself, but part of it is that I can somehow understand the search result or the relation between the query and the list of results that are shown. For the natural language search this is an unclear thing to me.

P.P.P.S.: Thinking about pasting search terms, where you do not want to type extra quotes, and comparing to natural language search where, I assume, you would be typing in the query anyway, would it be sensible to swap things around, i.e. have the "normal" search on by default and activate the natural language search through some extra characters (quotes, or "nat:query" etc. etc.)?

[jahmesmoore-star]