Working One Repository Signal Into a Booked Meeting

You spotted a company in your repository's activity: a fork, a pull request, an integration issue, someone starring twice in a week. This guide takes that single event and carries it all the way to a booked meeting with someone who can buy, or to a clean kill with a reason. It is for founders selling their own developer tool, account executives, SDR leads, and partnerships teams who work live GitHub signals rather than bulk lists.

The library already covers bulk list-building from dependency manifests, scoring open-core accounts, and defining when a repo lead is sales-ready. This is different. I follow one event end to end, with the real intermediate counts and the wrong turns most reps take: the hobbyist fork, the unreachable developer, the wrong buyer. Run your own live signal alongside the worked case below.

One honest limit up front. My exclusive index figures were unavailable when I built this, so every number here comes from primary and public sources, cited in plain terms. Where a figure is not publicly established, I say so and tell you what to check locally instead.

What a repo signal is and why one event is fragile

A repo signal is a single public action on your repository that suggests a person or company is evaluating your project. The trouble is that one action is rarely enough to act on, because most of the identity, intent, and reachability behind it is missing.

Three things are true at once, and they shape everything that follows. The event may be inauthentic, because the fake-star economy has poisoned one of the most common signals. The actor may be unreachable, because GitHub deliberately hides most contact information. And the actor, even when real and reachable, is almost never the person who signs the contract. Each of those is a fork in the road where you decide to proceed, corroborate, or walk away.

The worked example I carry through: an engineer with the login I will call the actor opens an integration issue on your repository, asking how your tool handles authentication behind a specific proxy. That is a high-effort event. It is not a drive-by star. It is the kind of signal worth spending an hour on, and it is the kind that most often stalls in the middle.

The forks in the road, before you spend an hour

Three decision points decide whether a signal is worth resolving at all. Classify the event by effort, score the account for authenticity, and confirm the actor could plausibly be commercial. If a signal fails any of the three, you kill it in minutes rather than losing an hour to a hobbyist fork.

The first fork is event type. A fork or a pull request implies actual use, which makes it a stronger commercial tell than a star. A star costs an adversary almost nothing, and stars have sold for $0.03 to $0.85 each. A CMU study published at ICSE 2026 found 6 million fake stars across 18,617 repositories, using 301,000 accounts, with AI and LLM repos the largest non-malicious category. At the July 2024 peak, roughly 16% of all repositories with star activity were associated with fake-star campaigns. So weight your events by effort, not by count.

The second fork is account authenticity. The tells are consistent across the published detection work: zero-follower accounts, fork-to-star ratios far below organic baselines, and accounts created the same week as the activity. In one sampling analysis, repos were found where 36 to 76% of stargazers had zero followers, with fork-to-star ratios roughly 10x below organic baselines.

Table A: authenticity filters to run in two minutes

For my worked example, the actor has 40 followers, a two-year-old account, and eight real repositories with recent commits. That passes. This is a real person, not a bot.

Resolving the developer to a company and a reachable email

The documented resolution chain is: read the profile, then read public commit emails, then fall back to the GHArchive event stream. Each step leaks, and for most single signals you will not reach a deliverable address at all. That is the norm, not the exception.

Start with the profile via the users endpoint, which exposes company, blog, and email fields. The email field is null for the vast majority of users, so do not count on it. The company field, when set, is your fastest route to an employer, but it is free text and often stale or a joke.

Next, read public commit metadata for an author email. Here is the first trap. Many developers use the masked alias id+username@users.noreply.github.com as their commit email, which is GitHub's privacy feature and does not accept inbound mail. GitHub links a commit to a user by matching the email in the commit header to an email on a GitHub account, so the header is where the address lives, but the address you find may be a mask that silently bounces.

The archive route is the hardest. The API does not expose user emails, commits get rewritten to noreply, and the events archive ships hashed addresses, so resolving a login to a deliverable email takes real work. Attribution is also noisy: people commit under a nickname, an initial, a name like "Acme CI Bot", or a coworker's name because they cloned a repo on someone else's machine.

Confirm the identity before you trust the address. A finder resolves a username to a work email by reading commit metadata and then cross-referencing profile, organization, and package-registry signals to confirm which address the person still uses. Skip this and you email a coworker or a bot.

For my worked example: the profile company field reads a plausible current employer, a mid-size infrastructure company. Commit emails show two addresses. One is a users.noreply.github.com mask, which I drop. The other is a personal Gmail, which I flag for the legal check later. Cross-referencing the actor's package-registry publishes confirms the employer. I now have a name, a company, and one usable-but-risky address.

Manually, the resolution chain is where most of your hour goes and where most signals die. Asking Refolk for the people behind an event, already resolved to an employer and a work email, removes the exact friction the last four paragraphs described. That is the difference between a signal you can act on and one you abandon at the archive step.

Budgeting your API calls

If you resolve by hand against the GitHub API, know your ceiling. Unauthenticated requests are capped at 60 per hour per IP, which burns out on a single repo's stargazers. Authenticate.

An authenticated token supports roughly 83x the volume of unauthenticated access, so a personal token is the minimum viable setup for any real resolution run.

From the developer to someone who can actually buy

The developer who fired the signal is an end user and a potential champion, not the economic buyer. The champion is almost always an end user with enough political capital to push a project forward, but between them and a signature sit a technical evaluator and a budget holder.

The technical evaluator, typically an IT or engineering lead, reviews security, integrations, and reliability. The economic buyer, usually a director or VP with budget authority, owns the business case and signs off on ROI. Naming both is the work that turns a signal into a deal you control, because a deal with no identified economic buyer is a deal you do not actually control.

The scale of the problem is why you cannot stop at the developer. Enterprise buying committees average 13 stakeholders for general B2B purchases, and technology decisions pull in 25 or more people. Worse for the rep, buyers complete roughly 57 to 70% of evaluation before contacting a rep, so by the time your signal fires, the committee is already deep into its own process. Your job is to insert yourself into a decision that is already moving.

One signal is a coin-flip; a named economic buyer is what converts it into a deal you can forecast.

For my worked example: the actor is the champion. I search public LinkedIn and Crunchbase records for their reporting line and find a Director of Platform Engineering above them, who is the plausible technical evaluator, and a VP of Engineering with budget authority above that. I now have three seats, two of them worth emailing. The developer gets a specific, technical first touch. The VP gets a business-case second thread.

The lawful-basis check before you send

Which law applies is decided by where the recipient sits, not by how strong your signal is. Run this check before the first email leaves, because the same commit-mined address can be lawful in one jurisdiction and a breach in another.

In the US, CAN-SPAM permits B2B cold email with no prior consent, provided you follow its rules: honest headers, honest subject lines, ad disclosure where required, a physical postal address, a working opt-out, prompt opt-out processing within 10 business days at no fee, and monitoring anyone you hire to send. The stakes are real. Penalties run up to $53,088 per individual email under the current adjustment.

In the EU and UK, GDPR permits B2B cold email under the legitimate-interest basis in Article 6(1)(f), provided the message is relevant to the recipient's professional role, you disclose where you obtained their data, and you include a clear opt-out. Opt-outs must be processed within 30 days, and fines reach up to 20 million euros or 4% of global annual revenue.

The critical point for a commit-mined contact: using data from personal profiles for cold emailing without consent may violate GDPR, so stick to publicly available business contact information. That personal Gmail I flagged earlier fails the EU test. If my actor sits in Berlin, I cannot use it. I need their work address or I do not send.

Purpose test: I am contacting a professional about a tool relevant to their stated engineering role, evidenced by their public activity on my repository.
Necessity test: Direct email is the proportionate way to reach this role; no less intrusive route reaches a named buyer at this account.
Balancing test: The recipient would reasonably expect professional outreach given their public, work-related activity; I use a business address, disclose my data source, and offer a one-click opt-out.
Data source disclosed in email: public GitHub activity on [repository].
Opt-out: honored within 30 days, no fee.
Date: ____________________

One page covering the three tests, dated before campaign launch, is sufficient for most B2B cold email operations. For a US recipient, you skip the LIA and make sure the CAN-SPAM footer is present instead.

The procedure, one signal end to end

Here is the full run, from raw event to booked meeting or clean kill. Each step names what done looks like so you know when to move to the next fork.

Timing, sequencing, and the numbers to judge yourself against

Speed beats copy on a repo signal, so send inside the 24 to 48 hour window and reference the specific event. An email sent within 24 to 48 hours of a relevant buying trigger achieves 3 to 5x higher response rates regardless of the day or time. Intent beats calendar: a hiring announcement at Friday 3 PM beats Tuesday 10 AM by 3 to 4x, and the gap between the best and worst sending day is only about 2.1%. A same-day mediocre email out-books a polished one sent next week.

Keep the first email under 80 words, inside the optimal 50 to 125 word range, and make the first line about their specific repo action. Then sequence. Send 2 to 3 follow-ups maximum: the first lifts responses by 49%, the second adds 3.2%, and the third reduces responses by 30%. So follow up twice, no more, and use one of those threads to reach the economic buyer.

Judge the campaign against published baselines, not against hope. The platform average reply rate is 3.43%, the top quartile hits 5.5%, and elite campaigns exceed 10%. Top campaigns book 2 to 3 meetings per 100 emails sent.

Table B: benchmarks for a repo-signal campaign

The math tells you why one signal is a coin-flip. At a 3.43% reply rate, roughly 29 emails yield one reply, and at 2.5 meetings per 100 sends, roughly 40 sends produce one meeting. A single event resolved to a single address is not a campaign. Multi-threading to the buyer is what pulls a lone signal above the baseline, because it doubles your shots inside one warm account.

Subject: your proxy auth question on [repo]

Saw you opened the issue about auth behind a proxy on [repo] yesterday. That path trips up most teams running [setup], and we shipped a fix for exactly that case.

Happy to send the 2-line config, or walk your team through it in 15 minutes this week. Either works.

[Your name], [company]
[Physical address]
Not relevant? Reply "stop" and I will not follow up.

How this goes wrong: the failure modes

Most kills happen for a handful of repeatable reasons. Learn to spot each one by what it looks like when it lies, and you save hours and stay out of legal trouble.

• The masked email trap. You find a commit email that is actually a users.noreply.github.com alias. It looks like a valid address and silently bounces. Check the domain and drop it.
• Wrong-person attribution. The commit author name belongs to a coworker or a CI bot, not the actor. Cross-reference the login against org membership and package registries before you trust it.
• The hobbyist fork. A student or researcher forks to learn, not to buy. It looks like high enthusiasm with zero buying power. A fork with no company and no downstream activity is a kill.
• Fake-star inflation. You treat a star spike as demand when it was manufactured. At the July 2024 peak, about 16% of star-active repos had campaigns, and bot accounts show zero followers and same-week creation. Filter on account age and follower count.
• Single-threaded to the developer. You book the champion and stop. A deal with no identified economic buyer is one you do not control. Name a budget holder before forecasting.
• Missed window. Outreach lands a week late and reads as generic, so the 3 to 5x trigger lift decays. If you cannot send within 24 to 48 hours, reference the event explicitly or expect baseline rates.
• Personal-address GDPR breach. A commit-mined Gmail for an EU developer is a personal address, and messaging it on legitimate interest is shaky. Verify a business address before sending.
• Deceptive-subject reflex. A subject like "Re: our conversation" when none happened is a CAN-SPAM violation at up to $53,088 per email. Every subject line must reflect the body.

Before you hit send: the checklist

Run this against every signal you decide to carry forward. If any item fails, you either corroborate it or kill the lead with a reason. Nothing here is optional.

Keeping the play current

Two of the facts this play leans on will drift, so re-check the mechanism rather than trusting a stored value. The fake-star share moves as GitHub enforces its Acceptable Use Policies, which prohibit inauthentic interactions and automated starring; by January 2025, 90.42% of flagged repos and 57.07% of flagged accounts had been deleted. Re-run your authenticity filter each quarter against a repo you trust to recalibrate what an organic baseline looks like.

The legal thresholds also change. The CAN-SPAM per-email penalty is adjusted periodically, and GDPR enforcement evolves. Confirm the current figure and the current guidance from the FTC compliance guide and your own counsel before you scale a program, not after.

The one thing that will not drift is the shape of the work: a fork beats a star, most developers are unreachable, and the buyer is never the person who fired the signal. Build your process around those three, keep your window at 24 to 48 hours, and every fresh event has a repeatable path to a meeting or a fast, honest kill.