GitHub Lead Generation: From Stars to a Shortlist You Can Review

1. Define what would make a profile relevant

Write the product, technical use case and evidence you would accept before collecting names. “Python developers” is too broad to explain a match. “People with original public projects that deploy a FastAPI application” is a criterion you can inspect.

Also write an exclusion. A fork with no visible changes, a tutorial exercise or work on the framework itself may need a different decision from an application maintained by its user. These are review distinctions, not automatic rejection rules. State what you still need to learn about a person’s role and problem.

2. Check what audience evidence is accessible

In its June 30, 2026 notice, GitHub announced that stargazer and watcher lists, including related views, would be restricted to repository admins and collaborators. Its current REST documentation also describes the stargazer-list restriction. A public star count does not mean the underlying list is available to your research account. Read the access notice and the current API guidance.

Agree the accessible source before promising a complete audience. If a check is unavailable, record that state. Do not turn an access failure into “this person has not starred the repository,” or describe a partial historical sample as all current stargazers.

A historical event can still explain how a candidate entered a research queue. GitHub’s event documentation records an action and its time. An event at that time does not establish that the relationship persists today. Contributions and discussions can be researched as their own source types, with their own limits.

3. Label each source before interpreting it

Keep source coverage separate from fit. A person can have useful project evidence while their current-star status is unknown. Conversely, a verified star can coexist with no visible evidence for your use case. A single “qualified” score hides those differences.

A worked example: framework versus application template

Illustrative product criterion: imagine a tool intended for teams deploying FastAPI applications. The two repositories below are real; the product criterion and fit judgments are examples. We reviewed pinned READMEs on October 22, 2026. We did not qualify any individual, collect contacts or establish anyone’s buying intent.

The next step is to inspect a candidate’s own relevant work, record the source and explain why it meets the criterion. Do not copy the template’s properties onto every person associated with either repository. A source link should let the reviewer check the same observation you used.

4. Review a small batch with explicit decisions

For each profile, write an evidence statement and a separate judgment. “This project documents a FastAPI deployment” is an observation. “Worth reviewing for our deployment tool” is a judgment under the illustrative criterion. “Ready to buy” is a different claim, requiring evidence the project alone does not provide.

• Review further: a relevant observation supports the next question you want to investigate.
• Exclude for this scope: a documented mismatch explains the decision.
• Unresolved: the needed source or role evidence is absent or inaccessible.

Track public contact evidence independently. Include its attributable source when available; keep missing contacts missing. A contact source is not mailbox verification, and a completed research row is not a commercial conversion. Review the evidence quality before expanding the batch.

5. Use a review sheet that keeps the gaps

The CSV template has a header and no personal data. Add one row per candidate and keep original URLs, dates and the reason for your decision. Use an explicit unknown state where a check is unavailable.

Product and use case:
Repository and accessible source:
Evidence required for a match:
Exclusions and unresolved checks:

For each candidate:
Source relationship + observation date
Relevant project + original source URL
Fit judgment + reason
Public contact source + verification status
Next review decision

Common questions