The Repo-Engagement Account Standard: Work Now, Nurture, or Discard

This is the qualification standard for a weekly feed of GitHub activity: stars and forks on your own repo, plus issues, pull requests, and comments on competitor repos. It is for founders, account executives, SDR leads, and partnerships teams who need every rep to give the same batch the same verdict for each account: Work Now, Nurture, or Discard. It sets out six criteria, each with a pass threshold and a verification step, an eight-step grading procedure, and the failure modes that produce false positives.

What does this standard decide?

For each company that shows up in a week of repo-engagement events, it decides whether a rep works the account today, parks it in nurture, or throws it out. You grade the account, not the GitHub user, because one developer starring a repo proves almost nothing about whether a company is buying.

Terms used throughout:

• Signal: one public GitHub event, such as a star, fork, issue, pull request (PR), or issue comment.
• Actor: the GitHub account that produced the signal.
• Verified developer: an actor that passed authenticity, was attributed to an employer, and survived de-duplication.
• Account: the company, keyed on its primary web domain.
• Verdict: the single outcome assigned to an account for the week.

The three verdicts:

• Work Now: a rep contacts the account this week. All six criteria pass and the compliance record is complete.
• Nurture: the account is real and attributed but not yet corroborated. It goes into a sequence or watchlist and gets regraded when new signals arrive.
• Discard: the account fails a hard gate and is removed from the feed. The reason is recorded so the same rows do not come back next week.

Why accounts and not users? The published frameworks for open-source buying intent climb from individual curiosity to company-level commitment. Scarf's open source qualified lead (OQL) tiers run from OQL1, which "suggests investigative interest", through OQL2, "active usage", to OQL3, which "hints at potential commercial intent". Product-qualified lead (PQL) definitions add a headcount floor. One requires that "at least two users have completed a core action", and another uses "3+ active users from same company domain". Nobody has published a minimum for repo-engagement data, so this standard states one outright: two distinct verified developers.

A star is a bookmark. It becomes an account only when a second engineer at the same company shows up.

The six criteria and their pass thresholds

Every account is checked against six criteria: legitimate data route, signal depth, employer attribution, authenticity, recency window, and account-level corroboration. The table gives the pass threshold and how a rep verifies it. Later sections explain what each criterion proves and how it can mislead.

Verdict rules, applied in this order:

1. Discard if any event the account depends on fails the data route, if no actor at the account passes both authenticity and attribution, if every event is older than 180 days, if the only actors are your own staff or competitor staff, or if the compliance check hits a suppression list or an unconsented sole trader.
2. Work Now if two or more verified developers have qualifying events within 90 days, at least one of them at T1 or T2, and the compliance record is complete.
3. Nurture for everything else that survived step 1. That covers one verified developer at any depth, two or more at fork, star, or watch depth only, qualifying events 91 to 180 days old, or an incomplete compliance record.

Which GitHub data routes are legitimate?

There are three legitimate routes: star and watch data on a repo you administer, public issues and pull requests, and public forks and events. Star or watcher lists for anyone else's repo do not qualify, because GitHub now limits those endpoints to the repo's own admins and collaborators.

GitHub's changelog sets out the restriction. The stargazers endpoint (/repos/{owner}/{repo}/stargazers) and the watchers endpoint (/repos/{owner}/{repo}/subscribers) are limited to admins and collaborators. /users/{username}/subscriptions is deprecated and returns empty responses during the deprecation period. The /stargazers, /stargazers/you_know, and /watchers UI views are covered too, and callers may get empty responses or a 403. The star count stays public. Who starred, and when, does not. GitHub then shipped a star history endpoint that returns exact daily counts for any public repo. It gives counts, not identities, which makes it useful for screening repos and useless for finding leads.

Two limits on that table:

• The fourth row is an inference. Issues, PRs, forks, and the public events API are not on the restricted list, but I found no GitHub statement confirming they will stay unrestricted. Re-read the changelog at every policy review.
• Archive-derived star events are unverified. The StarScout research ran SQL over the GH Archive event dataset, which shows GH Archive carried star events up to 2024. Whether star events (WatchEvents) still reach it after the restriction is not publicly established. Until you have checked, treat any archive-derived star event on a repo you do not administer as failing the route criterion.

How much does each signal prove?

Depth ranks signals by how much effort they cost the developer. A pull request or committed code proves the most, then an issue, then a fork, then a star, then a watch. An account needs at least one issue-level or deeper signal to reach Work Now.

Grading notes that keep two reps aligned:

• Grade the event, not the person. One actor with a star and an issue contributes one verified developer at T2, not two signals.
• Substantive means about the product. A comment that only says "+1" or "same here" grades as T4, not T2.
• Code in a repo means committed usage. The developer's own public repo imports or configures the product. A README mention or awesome-list entry does not count.

What the recency window is based on

Nothing published supports a specific window, so this standard sets one as policy.

The policy window:

• 0 to 90 days: counts fully toward Work Now.
• 91 to 180 days: counts toward Nurture only.
• Over 180 days: struck. The event does not count.

The 90-day line sits at the short end of the unmeasured 3 to 6 month band, which is the cautious choice. Swap in your own numbers once you can show meetings booked against event age.

Authenticity: why screen the repo before the actor?

Screen the repo that carries the signal first, then the actor. Fake stars cluster on the repos that paid for them, so one repo-level check removes more noise than any amount of checking individual users.

The scale is large. StarScout, a CMU study, found 6.0 million fake stars and 18,617 campaign repositories over the period it covered. Enforcement leaves residue: GitHub removed 90.42% of flagged repositories but only 57.07% of the flagged accounts. Those surviving accounts can still turn up as engagement on other repos, your competitors' included.

Repo screen: forks per 1,000 stars

Forking takes effort and starring does not, so the ratio of forks to stars is a cheap repo-level check on real use.

Pass threshold for a source repo:

• Suspect if it has 52 or fewer forks per 1,000 stars (the highest manipulated value in the baseline), or if its daily star history shows spikes that do not line up with a public launch.
• Clean otherwise.

On a suspect repo, strike star and fork events, keep issue and PR events, and screen their actors as normal. Know the limits of this check: the baselines come from a secondary analysis that is not peer reviewed and covers a handful of repos. Before adopting the 52 line, calibrate it against two or three repos in your category that you know to be organic.

Actor screen

StarScout's actor rules carry over directly. Its low-activity rule flags an account whose public activity is one star plus one other event. Its lockstep rule flags at least 50 accounts co-starring at least 10 repositories, with half the co-starring inside 30 days. In its confirmed set it detected 81% of repositories and 76% of accounts, so expect it to miss some fakes.

An actor fails authenticity if any of these hold:

• It is a bot: a [bot] suffix, dependabot, or other known automation.
• It belongs to a lockstep group that meets the thresholds above.
• It matches the low-activity rule and has no rescue evidence, meaning no later issue or comment and no matching corporate commit email.

Record zero public repos and zero followers, but neither one fails an actor on its own. In one flagged repo, 32.7% of accounts had zero repos and 52% had zero followers. Real new evaluators look the same way. Applying StarScout's thresholds to individual leads is Refolk's policy. No published standard for screening leads exists.

When does a GitHub profile count as tied to an employer?

A profile counts as tied to an employer in two cases: a dated commit email on the company's domain names that employer, or the profile's company field does and a current external professional profile confirms it. Anything less, including the company field on its own, is unattributed and does not count toward an account.

Commit email is "considered the most accurate source of affiliation data" in the research, but coverage is thin because many contributors commit from consumer addresses.

With email alone, most actors in some ecosystems never reach an account, so the second route is required, not optional. Pass thresholds:

• Route A, commit domain. The commit email is on the account's corporate domain, the commit falls within the 180-day window, and no current external profile contradicts it. Affiliation is fixed "at the time of each commit", so an old commit shows a past employer.
• Route B, company field plus corroboration. The free-text company field, normalised (the research gives "@elastic, Elastic, Elastic Inc" as one company), matches the account, and a current external professional profile names the same employer. GitHub's company field is free text and unverified, so it never passes alone.
• Not accepted alone: organisation membership, freemail commit addresses, or a bio mention. I found no study that measures how accurate org membership or profile matching is against ground truth, so that accuracy is not established.

Route B is the slowest part of the weekly pass. Each handle has to be matched by hand to a current professional profile and an employer domain. Refolk searches GitHub, LinkedIn, and the open web in one plain-English query, so the handle, the current employer, and the repo activity come back in the same row and the rep only has to confirm the match.

The grading procedure

Run the eight steps in this order every week. Cheap, high-yield discards come first, so attribution effort only goes on events that survived. Sources disagree on the order: Refolk's earlier repo-signal standard ran attribution before the disqualifier screen, yet also said the gate "should sit on the source repo first". This standard follows the second instruction.

On timing: nobody has measured how long each step takes. Time your first three batches to find where the hours go, which is usually attribution.

How does repo-engagement grading go wrong?

Most errors are false positives that look like evidence. Each failure mode below has a specific check, and a rep should be able to name the check before overriding a criterion.

1. Route laundering.

   • Looks like: an enrichment list sold as "public data".
   • Actually: competitor stargazers scraped before the restriction.
   • Check: ask for the route tag on every row, and reject any star event on a repo you do not administer. A vendor that cannot say where a row came from has answered the question.

2. Low-activity false positive.

   • Looks like: a throwaway account that starred one repo and did one other thing.
   • Actually: a real evaluator who opened an account to try the product.
   • Check: look for a later issue or comment, or a matching corporate commit email. Either one rescues the actor.

3. Lockstep false positive.

   • Looks like: coordinated stars from many accounts at once.
   • Actually: a launch-day or conference spike.
   • Check: line the spike up against the public launch date in the daily star history. Lockstep needs 50+ accounts across 10+ repos, and one viral day on one repo does not meet that.

4. Stale employer.

   • Looks like: a clean commit email on a target company's domain.
   • Actually: a former employer, because affiliation is fixed at each commit.
   • Check: compare the commit date with the current external profile. If the profile shows a move after the commit, the actor counts for the new employer or for nobody.

5. Company field spoof.

   • Looks like: "@bigco" in the profile.
   • Actually: an aspiration, a past job, or a joke.
   • Check: the field never passes alone. Confirm it with a commit domain or a current external profile before counting the actor.

6. Double-counted account.

   • Looks like: two verified developers at one company, which would trigger Work Now.
   • Actually: one person with two handles, or a bot such as dependabot.
   • Check: dedupe by email or name and exclude [bot] accounts before counting. This mistake inflates the most Work Now verdicts, because the corroboration threshold is two.

7. Competitor or own staff.

   • Looks like: deep T2 engagement on a competitor's issue tracker.
   • Actually: the competitor's employees answering their own users, or your own team.
   • Check: exclude your own org members and known competitor domains before the roll-up.

8. Subscriber misclassified.

   • Looks like: a corporate account cleared for outreach.
   • Actually: a sole trader or a personal domain.
   • Check: run a company register lookup and a freemail screen. Sole traders need consent or the soft opt-in, and neither exists for a cold prospect.

The pattern in that list is worth stating plainly. Failures 1, 4, 5, and 6 all produce Work Now verdicts that should have been Nurture or Discard. Failures 2 and 3 do the reverse and throw out real buyers. When two reps disagree, check those six first.

Recording the verdict and keeping the standard calibrated

A verdict counts only when it is written in a record that a second rep could regrade without asking questions. Work Now also needs a compliance record completed before anyone is contacted.

The compliance fields

These come from UK ICO guidance, the only jurisdiction sourced for this standard:

• Subscriber type. Corporate subscribers need no PECR consent, but "you should comply with a corporate subscriber's opt-out request". Sole traders and some partnerships can only be emailed with consent or under the soft opt-in, and the soft opt-in does not extend to new prospects.
• LIA reference. Relying on legitimate interests requires the three-part test, documented as a legitimate-interests assessment (LIA).
• Suppression-list check. Run it against your own opt-outs before every Work Now.
• Opt-out route. Write down how the recipient will be able to stop contact.

EU member-state rules and US CAN-SPAM were not verified for this standard, so check them with counsel before applying the verdicts outside the UK. UK rules are also changing as the Data (Use and Access) Act phases in, so re-read the ICO's B2B guidance at every policy review.

Account domain:
Grading date:
Verified developers (handle | tier | event link | event date | evidence type A/B):
  1.
  2.
Struck events and reason (route / suspect repo / actor fail / out of window / unattributed / staff):
Source repo status (repo | forks per 1,000 stars | clean or suspect):
Deepest tier in 90-day window:
Distinct verified developers in 90-day window:
Subscriber type (corporate / sole trader / partnership):
LIA reference:
Suppression check (clear / hit):
Opt-out route:
Verdict (Work Now / Nurture / Discard):
Deciding rule (quote the verdict rule number):
Graded by:

The agreement test

The standard works when two reps grading independently agree on at least 9 of 10 accounts. Test it before adoption, and again whenever a threshold changes:

• Pick 10 accounts from a real weekly feed, including at least two you expect to be borderline.
• Have two reps grade them separately using only this document and the template.
• Compare verdicts. For every disagreement, find the criterion where the two records first differ.
• Rewrite that criterion's threshold or wording until both reps would have graded the case the same way. Do not settle it by deferring to the senior rep.

Keeping it current

The criteria are stable but the inputs change. Review these at a fixed cadence:

• GitHub's changelog. Check whether issues, PRs, forks, or the events API have joined the restricted list. If they have, the data-route table changes before anything else.
• Archive coverage. Confirm whether star events still appear in public event archives before treating any archive-derived row as permitted.
• Your own conversion data. Record meetings booked by signal tier and event age. Once you have enough cases, replace the 90 and 180-day windows and the two-developer minimum with numbers from your own pipeline, and note the change in the policy header.
• Repo baselines. Recompute the fork ratio of organic repos in your category every few months, since a single suspect line cannot fit every ecosystem.

When the weekly feed outgrows manual attribution, use Refolk for the roll-up. Ask in plain English for the role you sell to at companies whose engineers touched a given repo, then grade what comes back against the same six criteria. The standard stays the same; the search just takes less time.