Short answer
Pull requests that touch integration or configuration code are the single strongest event-level predictor of near-term pipeline. Clusters of stars across competing tools are the strongest population-level predictor. Commits are only useful once you know which repo the commit lands in — commits to a fork of a competitor are high-intent, commits to the upstream community repo are low-intent. Weight signals by the effort each one requires.
TL;DR
- A single star is weak; clusters of stars across competitors are strong.
- Forks are roughly 5× more predictive than stars per event.
- Pull requests to integration code are the highest event-weight signal short of a migration-intent issue.
- Commits carry information only in context of the repo they land in.
- The right scoring function is a weighted sum — not a priority waterfall.
- Recency multiplier matters: weight last-7-days events 1.5× last-30-days.
Contents
The effort axis — why weight matters
Signal quality scales with the effort required to produce the signal. A star costs a click; a fork costs a click plus a decision to copy code; a pull request costs hours of work and usually at least one round of review. Effort is a proxy for commitment, and commitment is a proxy for buying intent. Any scoring framework that treats all events equally — or that applies only a binary threshold — will miss this.
The practical implication: you cannot build a signal-based pipeline that prioritizes stars over PRs and expect reply rates to hold. Stars are your raw material; PRs are your precision edge. Use them differently.
This matters for signal-based selling programs because the volume distribution is inverted against the intent distribution: you will see roughly 100 stars for every fork and 1,000 stars for every PR on a typical DevTool repo. Treating each signal at its own weight is how you avoid burning outreach capacity on low-probability events.
Stars: high volume, low confidence per event
A GitHub star is a public bookmark — a lightweight action that lets the developer find the repo again. Stars are the most common intent signal on GitHub and the most likely to be misread. Every star is a real action, but the intent distribution behind stars spans the full range from "casual bookmark" to "actively evaluating right now."
What stars are good for
Stars are best used as a population-level signal. Three stars from the same developer on three competing repos within 14 days is a far stronger signal than any single star — because the underlying behavior (comparison shopping) is only visible at the cluster level. Individual stars are the atom; star clusters are the molecule that carries the meaning.
What stars are not good for
A single star is not enough evidence to justify first-touch outreach. Reply rates on single-star outreach are low enough that the practice tends to train prospects to ignore you. Treat a lone star as a low-cost trigger to enrich the developer and hold them for a second signal.
Pull requests: low volume, highest confidence
A pull request is production-adjacent activity. The developer has written real code, committed it, and asked for review. PRs correlate with pipeline more reliably than any other single GitHub event because the effort floor is high: you do not open a PR against a tool you are not already using.
Not all PRs are equal
The repo the PR lands in matters. A PR to the upstream community repo — fixing a bug, adding a feature — is a contributor signal, which correlates with adoption but not necessarily with near-term buying. A PR to a fork of a tool, especially one that touches integration or configuration code, is a much stronger commercial signal: the developer is modifying the tool to fit their own environment, which almost always means they plan to use it.
Draft PRs are the best state
Draft and recently-opened PRs are higher-intent than merged ones. A merged PR is a retrospective signal — the work happened, and whatever evaluation cycle it was part of may already be complete. A draft PR is present-tense. Prioritize recent and in-flight PRs over merged ones when building an outreach queue.
Commits: context-dependent
A commit is the lowest-level unit of work on GitHub and also the most variable in commercial meaning. Commits only carry intent information when you know where they land.
High-weight commit contexts
- Commits to a fork of a category repo — strong evaluation or integration signal.
- Commits to a personal repo that imports the tool — indicates production or near-production use.
- Commits to company monorepos that touch integration paths — visible only on public repos but extremely high-weight when they appear.
Low-weight commit contexts
- Commits to the upstream community repo — indicates contribution, not buying.
- Commits to unrelated personal projects — useful only for seniority estimation.
- Commits attributed to a bot account — filter these out entirely (dependabot, renovate, Copilot-class accounts).
Building commit-level signals in production is more work than stargazer or fork monitoring because commit volume is orders of magnitude higher and the filtering is more nuanced. Most DevTool teams get more value from star/fork/issue monitoring first and layer commits in later. See GitHub activity as a buying signal for the full taxonomy.
Combining signals into a score
The right model for most teams is a weighted sum over a rolling 30-day window. A starting point that works in practice:
- Star on category repo: 1 point
- Star on competitor repo (explicit): 2 points
- Fork on category repo: 5 points
- Commit on fork: 6 points
- Issue opened (non-migration): 3 points
- Issue opened referencing a competitor by name: 10 points
- Pull request (draft or recent): 8 points
- Pull request to integration/config code: 12 points
- Recency multiplier for events in last 7 days: ×1.5
Developers above a 10-point rolling total are your working queue. Developers above 20 are drop-everything priority, typically reached through a fork-plus-PR or a migration-issue-plus-fork combination.
This framework lives downstream of a reliable developer signal intelligence pipeline. If your upstream data has gaps — missed events, stale enrichment, bot contamination — the score will overfit to noise. Get the signal stream clean before tuning the weights.
What to filter out
Not every event that fires is useful. Three categories deserve to be filtered before scoring:
- Bot accounts. dependabot, renovate, Copilot-style accounts, and CI bots generate volume but no intent. Explicit allow/deny lists outperform heuristics here.
- Self-references. Stars and forks by the repo's own maintainers or their colleagues are not buying signals.
- Repeat events from the same developer on the same repo. A star plus an unstar plus a re-star on the same repo is one event, not three.
Frequently asked questions
Which GitHub signal is the strongest predictor of B2B pipeline?
A PR to integration or configuration code is the strongest single-event signal. A cluster of stars across competitors is the strongest population-level signal.
Are stars a reliable buying signal on their own?
No. Single stars are noisy. Stars become reliable when they cluster across competing tools or combine with a second signal from the same developer.
What does a commit tell you commercially?
It depends on the repo. Commits to forks of category repos are high-weight; commits to the upstream community repo are low-weight; commits by bots are filtered.
How should I weight forks vs. stars?
Five to one. Forks require hands-on intent; stars require a click. The weight difference is durable across repos and categories.
Do draft PRs count as signals?
Yes, and usually more strongly than merged ones. Draft PRs are present-tense evidence of work in progress.
Which signal has the lowest false-positive rate?
Issues that explicitly name a competitor. The developer has stated both the context and the intent to change tools.
Weight your signals correctly
LeadCognition monitors stars, forks, PRs, and migration-intent issues across your category repos and scores every developer automatically. Start the free trial.
Start free →