--- title: "GitHub sourcing: people search and project evidence" canonical: https://metix.ai/blog/github-sourcing published: 2026-10-19 updated: 2026-10-19 author: "Metix AI" --- # GitHub sourcing. People search and project evidence. Canonical: https://metix.ai/blog/github-sourcing Find an account, inspect a project, then ask what the evidence actually supports. A public engineering role and a merged change show how to keep those steps separate. Metix AI editorial teamResearch & hiring guides The short version Use Users search to discover accounts and Repositories search to find relevant projects. Inspect a specific contribution, preserve its source and version, and separate what you saw from what you still need to ask. A count, language label or popular project does not qualify a candidate. Decision guide ## What can you establish from public work? 1. ### Define the role Write the criterion and acceptable evidence before filtering. 2. ### Inspect the work Read a concrete change and preserve the source revision. 3. ### Resolve the gaps Name the reviewer and next question before outreach. Public code is partial evidence. The worked role and PR are editorial examples, not a candidate recommendation or a customer activation. Public sources and search results checked October 19, 2026. The public vacancy and pull request below are an editorial exercise. No candidate was assessed or contacted on the employer's behalf. ## Start with a role, then decide what evidence would help GitHub sourcing helps recruiters find developer accounts and inspect public engineering work. It is useful when a hiring manager can explain which work relates to the vacancy and a technical reviewer can evaluate it. A search result is a starting point for that review, not a qualified candidate. For this exercise, we used Automattic's public [Experienced Software Engineer advertisement](https://automattic.com/work-with-us/job/experienced-software-engineer/). It describes production software experience, debugging through abstraction layers and work at scale. PHP and JavaScript are the main languages. The advertisement asks applicants to be comfortable becoming an expert. We therefore treat previous mastery of both languages as a question for the hiring manager, not an extra mandatory filter. That distinction changes the search. WordPress-related projects can reveal relevant work, but a PHP-only filter can narrow discovery too early. A repository's primary language does not describe every contribution or every contributor's skills. The role is global; London is not a required location. [Download the blank role brief and filled example (Markdown)](https://metix.ai/assets/resources/github-sourcing-role-brief.md). Replace the example with a vacancy you are authorized to fill. Name the reviewer, write the mandatory criteria, identify what is trainable and leave unanswered questions visible. ## Choose Users or Repositories before adding filters GitHub has separate search surfaces. Users search returns accounts. Repositories search returns projects. Choose the result type before interpreting the query or its count. **Two search scopes and the limits of their evidence** | Surface | Useful qualifiers | What remains unproven | | - | - | - | | Users | `type:user`, `language:`, `repos:`, `location:` | Technical depth, current interest, employment eligibility and role fit | | Repositories | `org:`, `topic:`, `in:name`, `language:`, `archived:`, `pushed:` | Who did the relevant work, their responsibility and their availability | GitHub's [user-search documentation](https://docs.github.com/en/search-github/searching-on-github/searching-users) defines language as languages in repositories associated with a user. It is a discovery hint. Profile location is self-declared and cannot settle working hours or employment constraints. The [repository-search documentation](https://docs.github.com/en/search-github/searching-on-github/searching-for-repositories) places stars and pushed dates on projects. A recent push reflects the latest project commit on any branch. It does not identify a particular person's latest contribution or demonstrate work on the default branch. Account creation date is account age, not years of professional experience. Use them to decide where to look next. Assess the person against the role after reviewing the work and asking about the missing context. ## Four queries tested against the public role We ran the following queries on October 19 at 04:17 UTC through GitHub's public search API, inspecting the first three results in its default order for each. The broad account and PHP-project queries were also checked in the browser. Counts are an observed snapshot, not qualified candidates, search demand or a promise of future results. ### 1. Find accounts associated with PHP work `type:user language:PHP repos:>=5` [Run in Users search](https://github.com/search?q=type%3Auser+language%3APHP+repos%3A%3E%3D5&type=users). The response reported 613,028 accounts. Five repositories is an arbitrary discovery threshold in this example. It does not measure quality or seniority, and it can exclude someone whose relevant work is private. ### 2. Observe what a location filter removes `type:user language:PHP repos:>=5 location:London` [Run in Users search](https://github.com/search?q=type%3Auser+language%3APHP+repos%3A%3E%3D5+location%3ALondon&type=users). The response reported 2,126 accounts. This demonstrates a location restriction, not a better shortlist. Our example role does not require London. Adding it would exclude accounts for a requirement we invented, and the profile field would still need confirmation. ### 3. Discover recently updated PHP projects in the relevant domain `topic:wordpress language:PHP archived:false pushed:>=2026-07-01` [Run in Repositories search](https://github.com/search?q=topic%3Awordpress+language%3APHP+archived%3Afalse+pushed%3A%3E%3D2026-07-01&type=repositories). The response reported 5,023 projects. The inspected results included roots/sage, woocommerce/woocommerce and roots/bedrock. The date narrows project activity; it makes no claim about any contributor's current job search. ### 4. Find a named project without a premature language restriction `org:WordPress gutenberg in:name archived:false` [Run in Repositories search](https://github.com/search?q=org%3AWordPress+gutenberg+in%3Aname+archived%3Afalse&type=repositories). Five projects were returned. The first three included Gutenberg with TypeScript as its primary language, wporg-gutenberg with PHP, and gutenberg-sync-engines with JavaScript. For a role involving the wider product, read relevant work before deciding that one language label is mandatory. [Download the editable query workbook (CSV)](https://metix.ai/assets/resources/github-sourcing-query-workbook.csv). Each row records the surface, actual query, observed count, time and limit. Use the empty columns for your own role requirement and revised query. Start with the requirement written in the role brief. Change one restriction at a time and record what disappeared from the inspected sample. A smaller count is useful only if the remaining evidence is more relevant; this exercise did not measure that improvement. ## Move from a project to one specific change WooCommerce appeared in the project query. We then read [pull request 69956, "Check order notes permission against the actual order type"](https://github.com/woocommerce/woocommerce/pull/69956), merged October 16. This is a public change relevant to a debugging conversation; its author is not being presented as a candidate or recommended hire. The patch replaces an order-notes permission check with a helper that considers the actual order type. It adds regression cases for a refund order type and a custom order type with its own capabilities. The PR description states that Claude Code wrote the fix and the test, and the author reviewed both. Record that declaration with the patch. A useful technical question is what the reviewer checked at the permission boundary and which regression would have exposed the old behavior. The merged change alone cannot establish unaided authorship, production ownership, broader JavaScript experience or the person's interest in your role. **Worked evidence row, checked October 19, 2026** | Field | What to record | | - | - | | Criterion | Debugging across abstraction layers | | Observed source | WooCommerce PR 69956; actual order-type permission helper and regression tests; explicit AI-assisted implementation declaration | | Version | PR head `6ba126422919da9c004169b4fa33e8e39600fc6e` | | Interpretation | A specific example a technical reviewer could discuss | | Unknown | Personal responsibility beyond the declaration, production scale, other skills, eligibility and current interest | | Next action | Review against your own role criteria, then seek appropriate clarification; no outreach sent in this exercise | We read the description and four-file patch. We did not execute the project's tests or independently reproduce the bug. Preserve the exact source revision so another reviewer can inspect the same work: [permission helper at the inspected head](https://github.com/woocommerce/woocommerce/blob/6ba126422919da9c004169b4fa33e8e39600fc6e/plugins/woocommerce/src/Internal/Abilities/Domain/Traits/OrderAbilityTrait.php). [Download the worked evidence log and blank row (CSV)](https://metix.ai/assets/resources/github-sourcing-evidence-log.csv). Keep the observed fact, your interpretation and the unanswered question in different fields. For your own role, add the reviewer's name and the next question before moving the row into a shortlist. For the worked example, ask how the order type affects the permission check, what the custom-type regression covers and what the author personally checked. The reviewer can disagree with the interpretation while keeping the source intact. ## Leave room for private work and missing context Public contributions cover only part of an engineer's work. Someone may spend their career in employer-owned repositories, contribute under another account or have little time for public projects. Offer another route to the same requirement, such as a discussion of a past production incident using information they are permitted to share. Record that alternative evidence against the same criterion rather than penalizing an empty public profile. Do not use stars, followers, contribution squares or account age as substitutes for that discussion. A popular project can help you find relevant work, but its popularity does not belong to every contributor. A quiet public profile does not establish weak skills. Keep recruiting separate from project maintenance. Do not place a recruiting pitch in a bug report or pull-request discussion. Use an appropriate contact route, confirm current interest, and honor do-not-contact requests. This workflow does not require extracting commit-metadata email addresses or building a contact database. ## Turn the evidence into a decision on your own vacancy Before handing a name to the hiring manager, attach the role brief and the source. Name the person responsible for resolving each unanswered requirement. Agree which gaps need a technical conversation before outreach and which are ordinary screening questions. If no relevant evidence is visible, change the route or stop; do not manufacture certainty to fill a list. Manual GitHub discovery suits a small number of technical searches when your team can inspect the work. If the need includes sourcing, approved outreach, reply handling and interview booking, test the broader workflow with your own authorized role. For Metix, create a real vacancy brief, set up an Agent, review match evidence and approve outreach. Your team owns those decisions on a self-serve subscription; staff shortlist review is not included. Delivery is a separately quoted service for teams needing people to operate the work. See [Metix plans and service scope](https://metix.ai/pricing). Keep GitHub evidence in your approved review process; the workflow described here uses manual public-source review. Metix has no public people-search API or MCP server, and we have not verified a native GitHub import. To judge a trial, record an actual role activation, approved work and subsequent outcomes separately from downloads or signups. ### Test one vacancy you are actually hiring for Bring the brief, name the reviewer and check the first match evidence before approving outreach. A 14-day trial includes 1 AI Agent and 500 Credits. No credit card required. ## Frequently asked questions ### How do recruiters source developers on GitHub? Start with an authorized role and an evidence standard. Use Users search for accounts and Repositories search for projects, then inspect a relevant change with a technical reviewer. Record observed facts, interpretation and unknowns before deciding on appropriate outreach. ### Can I use pushed dates to find active candidates? The pushed qualifier filters repositories by their most recent commit on any branch. It does not establish an individual contributor's activity, availability or current interest in a job. ### Do stars and followers show developer seniority? They do not establish seniority or role fit. Stars describe repository interest and followers describe account attention. Assess relevant work and ask about responsibility, technical choices and production context instead. ### What if a strong developer has no public code? Use an equivalent evidence route, such as a permitted discussion of a production incident or past technical decisions. An empty public profile does not establish weak skills. ### Does this workflow import GitHub candidates into Metix? This guide uses manual public-source review and does not verify a native GitHub import. Metix has no public people-search API or MCP server. For your own real vacancy, review match evidence and approve outreach in the Agent workflow; Delivery is a separate quote. ## Sources and what this exercise did not measure The query workbook contains four October 19 observations, with three results inspected per query. Counts and ordering can change. We did not measure sourcing precision, response rates, candidate performance or hiring outcomes. The role is a public illustration, not a customer assignment. We read [Pin's GitHub recruiting guide](https://www.pin.com/blog/github-recruiting/) and [daily.dev's GitHub sourcing guide](https://recruiter.daily.dev/resources/recruit-developers-on-github-sourcing-guide/), including their visual examples. The scope distinctions above follow GitHub's official documentation. Vendor success rates, follower thresholds and mixed-scope query recommendations were not adopted. Metix's [assistant resources](https://metix.ai/for-assistants) and pricing page define the product boundary described here. About the editorial team ## [Metix AI editorial team](https://metix.ai/about) Research & buying guides The Metix AI editorial team writes hiring guides and product comparisons. We publish source dates, distinguish vendor claims from observations, and keep worked examples separate from measured outcomes. Metix AI also sells recruiting software. [About Metix AI ↗](https://metix.ai/about) ## Next step See plans, Credit rules, and trial terms on the [Metix AI pricing page](https://metix.ai/pricing). A 14-day trial includes a one-time 1 AI Agent and 500 Credits, with no card required.