Alex: Welcome back. Today we're talking about GitHub advanced search, which sounds like a power-user feature, but it is really a way to stop wandering around the site when you already know what you want.

Jamie: I love that framing, because search is where I go when I can't remember which repo, issue, pull request, or file I saw something in.

Alex: Exactly. GitHub search can reach across repositories, code, issues, pull requests, commits, users, organizations, and topics. The trick is learning the small query language that narrows the results before you ever press Enter.

Jamie: So instead of opening menus and checking boxes, I can type a more precise sentence into the search field.

Alex: Yes. And if you use a screen reader or high zoom, that can be a big relief. A typed query often gives you a clean results page faster than moving through filter dropdowns, sidebars, and checkbox menus.

Jamie: Where do you start from on GitHub?

Alex: On most GitHub pages, press slash to focus the global search bar at the top. Type your query, press Enter, and GitHub opens a results page grouped by type, such as Code, Issues, Pull requests, Repositories, and Users.

Jamie: Global search is the one at the top of the page. But GitHub also has search boxes inside repositories, right?

Alex: Right. The global search bar starts broad, across all of GitHub unless your query narrows it. Inside a repository, the Issues tab and Pull requests tab have their own search fields, and those are already scoped to that repository.

Jamie: So if I'm in a repo's Issues tab, I don't need to type the repo name unless I want to be extra explicit.

Alex: Exactly. But when you're starting from the top search bar, you can scope the search yourself with qualifiers like repo:owner/name, org:orgname, or user:username. A qualifier is a key and a value separated by a colon.

Jamie: Give me a concrete one.

Alex: repo:community-access/accessibility-agents in:title keyboard searches that repository for results with keyboard in the title. The in:title part says, do not search every body and comment; focus on the title field.

Jamie: That would reduce a lot of noise. What about in:body and in:comments?

Alex: Those work the same way. Use in:body when the important detail is likely in the description, and in:comments when you're looking for discussion after the issue or pull request was opened.

Jamie: And if I do lose the search bar visually at high zoom, slash brings me back there.

Alex: Yes. After results load, screen reader users can jump by headings to move between result groups. Low vision users can also use browser zoom to make GitHub's bold matched terms easier to find, and the Advanced Search page at github.com/search/advanced is a good bookmark if you want labeled form fields instead of compact syntax.

Alex: The query language itself starts simple. If you type two words, GitHub treats that as both words. So keyboard navigation means results should match keyboard and navigation.

Jamie: And if I want either word?

Alex: Use OR in capital letters, like keyboard OR focus. For an exact phrase, put it in straight quote marks, like "skip link". To exclude a word, put a minus sign in front, like -deprecated.

Jamie: I have definitely needed that last one. Sometimes one noisy term takes over the whole search.

Alex: You can also exclude a qualifier. For example, -label:bug means results should not have the bug label. That same key:value pattern is the heart of GitHub search.

Jamie: Let's unpack the issue and pull request qualifiers people see all the time.

Alex: is:open means open items only, and is:closed means closed items only. is:issue limits results to issues, and is:pr limits results to pull requests. For pull requests, is:merged finds merged PRs, and is:unmerged finds PRs that were not merged.

Jamie: And labels?

Alex: label:accessibility finds items with that label. If the label has spaces, quote it, like label:"good first issue". no:label finds items with no labels, no:assignee finds items assigned to nobody, and no:milestone finds items not attached to a milestone.

Jamie: What about the human side, like who made it or who owns it now?

Alex: author:@me finds items you created. assignee:@me finds items assigned to you. mentions:username finds places where that user was mentioned, and involves:@me is broader: it can include things you created, were assigned to, were mentioned in, or commented on.

Jamie: Dates use the same style?

Alex: Yes. created:>2025-01-01 means created after that date. updated:<2026-01-01 means updated before that date. A range looks like created:2025-01-01..2025-03-31.

Jamie: Let's use this for issues and pull requests, because that is where a lot of contribution work starts.

Alex: A good direct place is github.com/issues for issues involving you, and github.com/pulls for pull requests involving you. Those pages are already focused on repositories you have access to, so the result list can feel more manageable than a full global search.

Jamie: What would I type if I wanted open accessibility issues in an organization, but only ones nobody has claimed yet?

Alex: org:community-access is:issue is:open label:accessibility no:assignee. That says: search this organization, only issues, only open ones, with the accessibility label, and no current assignee.

Jamie: That is much more precise than searching the word accessibility and hoping.

Alex: For beginner-friendly work across GitHub, try is:issue is:open label:"good first issue" no:assignee. If you want a language filter, add language:python or language:javascript.

Jamie: Does language always make sense for issues?

Alex: It depends. GitHub can use repository language signals, so it is useful when you want issues from projects mostly written in a language. It does not mean the issue text itself is written in Python or JavaScript.

Jamie: What about pull request review?

Alex: A daily review query is is:pr is:open review-requested:@me. If you need pull requests where someone mentioned you, use is:pr is:open mentions:@me. To find your own open issues, use is:issue is:open author:@me.

Jamie: And stale work?

Alex: Use a date qualifier. For example, is:issue is:open repo:owner/name updated:<2024-08-01 finds open issues in one repository that have not been updated since before that date.

Jamie: Pull requests have a few special qualifiers too, don't they?

Alex: They do. review:approved can find PRs with an approving review. draft:true finds draft pull requests, while is:draft is another common way to express that. head:branch-name searches by the source branch of a PR, and base:main searches by the target branch.

Jamie: So base:main is useful when I only care about PRs trying to merge into main.

Alex: Exactly. And once the results are right, sorting helps. sort:created-asc puts the oldest created results first, while sort:updated-desc puts the most recently updated results first.

Alex: Code search feels related, but it has its own behavior. GitHub's modern code search is built for files, symbols, paths, and exact strings, not just issue text.

Jamie: So if I want to find aria-label in JavaScript files inside one repo?

Alex: Use repo:owner/name language:javascript aria-label. That combines a repository scope, a language filter, and the text you want to find.

Jamie: What if I know the function name?

Alex: Try symbol:handleKeyDown with a repo scope, like repo:owner/name symbol:handleKeyDown. Symbol search is meant for named code things such as functions or classes, where GitHub can recognize them.

Jamie: And across an organization?

Alex: org:community-access aria-hidden="true" searches across repositories in that organization for that exact pattern. You can tighten it with path:src/ to search only files under a path, extension:md to search Markdown files, filename:config.yml for a specific file name, or content:"exact string" for an exact string in file content.

Jamie: I like path:src/ because it lets me ignore docs or generated files when they are not relevant.

Alex: Exactly. And org: and repo: are useful here too. repo:owner/name means one repository, while org:orgname means all repositories in that organization.

Jamie: Commits are searchable too, but I always forget that.

Alex: They are. A query like repo:owner/name fix keyboard navigation can find commits with those words in the message. repo:owner/name author:username finds commits by a specific author, committer-date:2025-01-01..2025-03-31 narrows by date range, and path:docs/README.md finds commits touching a specific file.

Jamie: Search is not only for work items and files. It can also help you discover projects.

Alex: Yes. Repository search is great for finding communities and examples. topic:accessibility stars:>50 is:public finds public repositories tagged with the accessibility topic and more than 50 stars.

Jamie: And if I want TypeScript projects related to screen readers?

Alex: language:typescript topic:screen-reader sort:stars-desc. That filters by language and topic, then sorts with the most-starred repositories first.

Jamie: What other repository qualifiers are useful?

Alex: stars:>100, forks:>10, archived:false, and pushed:>2025-01-01 are common ones. You can use them to avoid abandoned projects, or to find active projects with a certain amount of community activity.

Jamie: Can I search for people and organizations the same way?

Alex: Yes. User and organization search supports qualifiers like type:user, type:org, location:, and fullname:. You might search accessibility type:user, or accessibility type:org, then use the result type filters to narrow what GitHub shows.

Alex: In this workshop, search becomes especially useful when you're looking for contribution opportunities or checking whether a report already exists.

Jamie: So before I file a new issue, I can search for the problem first.

Alex: Exactly. In a repository, use terms from the problem plus is:issue. If the issue is about keyboard focus, a query like repo:owner/name is:issue keyboard focus in:title can quickly show whether someone already filed something similar.

Jamie: And for the Accessibility Agents work, we should treat that collection as a living catalog, not a fixed set.

Alex: Right. Challenge 15 is browse-first, so search can help you discover what is already there without requiring a fork. A query like repo:community-access/accessibility-agents is:issue is:open label:accessibility can help you find current discussion or possible work, depending on the repository's labels.

Jamie: Then Challenge 16, the Capstone Project, is broader than one repo.

Alex: Yes. A meaningful capstone contribution might be to Accessibility Agents, GLOW, or another repository where the work matters. Review-ready drafts and contribution plans can count as completion evidence, so search can help you gather proof, locate related issues, and avoid duplicating work.

Jamie: What about proof after the fact?

Alex: Use is:pr is:merged author:@me to find your merged pull requests. Add org:community-access or repo:owner/name if you need proof from a specific place. For recent discussion about a topic, combine the topic words with updated:>2025-01-01 and maybe in:comments.

Jamie: I know I can bookmark a results page, but is there a better habit than leaving a pile of random bookmarks?

Alex: Build a small personal search library. Save the searches you actually reuse: review requests, your open issues, beginner-friendly issues, stale issues in a repo you maintain, and proof of merged work.

Jamie: Because the query is stored in the URL after I run the search.

Alex: Exactly. You can bookmark that URL, keep it in a notes file, or make a Markdown table with the name of the search, the query, and when you use it. That turns search from a one-time trick into part of your workflow.

Jamie: And if I live in the terminal?

Alex: The GitHub CLI has gh search commands. For example, gh search issues "is:open label:accessibility no:assignee" can bring issue search into your command line, and gh search prs "is:open review-requested:@me" can help you check review requests without opening the browser first.

Jamie: So the same mental model carries over: words, qualifiers, scopes, dates, and sorting.

Alex: That's the key. Start broad only when you need to explore. When you know the repository, organization, state, label, author, date, or file path, put that knowledge into the query.

Jamie: And the payoff is not just faster search. It is fewer wrong turns, fewer duplicate issues, and a cleaner path to the contribution you were trying to make.

Alex: Well said. Advanced search is one of those skills that makes GitHub feel smaller, calmer, and much more navigable.