Public GitHub shipping activity as a diligence signal.

1. Problem

Investors, acquirers, analysts, and hiring managers routinely check GitHub profiles to gauge engineering activity. But raw commit counts, star counts, and contribution graphs are misleading without context. Monorepos inflate commit counts. Bots pollute activity graphs. Squash merges compress real work into single commits. Mirror repos create phantom activity. The result: public GitHub data is simultaneously the most accessible and most misread signal in software diligence.

2. Approach

ShipSleuth treats public GitHub data as a structured signal rather than a raw count. For any org, user, or repo, it decomposes visible activity into direct metrics that each answer a specific question:

3. How the overall rank is built

ShipSleuth shows each metric as its own percentile, plus one overall rank (for example, Top ~10%). The overall rank comes from an activity index built only from parts that can be measured for every public account, so it is computed the same way for the account being analyzed and for every account in GH Archive, and its cutoffs are measured like every other metric's. The index is never shown as a number, only the rank it lands on. It uses only what both sides can measure the same way; merged pull requests and contributors are ranked on their own. The four parts are weighted as follows:

4. Percentile calibration

Absolute metric values are hard to interpret without context. ShipSleuth assigns percentile badges (Top ~1%, Top ~5%, Top ~10%, Top ~25%, Top ~50%) using cutoffs measured from GH Archive, the public record of GitHub's event feed, queried on Google BigQuery (measured Oct 12, 2026).

Every preset window length, from 7 days to 5 years, is measured directly as its own window, and every one ends on May 31, 2025. From June 2025 on, GitHub's public feed records fewer events per account even as more accounts appear, so newer data would make everyone look more active than they are; the stretch ending May 31, 2025 is the last complete one. A length in between, such as year to date or a custom range, blends the two nearest measured lengths on a log scale of window length, and a window shorter than 7 days has no rankings. ShipSleuth used to measure a single quarter and stretch it to every length, which set short-window cutoffs far too low and long-window cutoffs too high; the methodology page shows by how much.

The population is every account with at least one public push in the window: ~1.5M accounts in 7 days, up to ~36.2M in 5 years. Bot and CI accounts are recognized the same way on both sides of every ranking, by a shared list of names and by logins ending in “[bot]”. They are at most ~0.2% of any window's pool, and the human-only view lowers cutoffs in proportion to each window's bot share.

Each metric is ranked against its own measured distribution (P50, P75, P90, P95, P99, P99.9 and P99.99). GH Archive records pushes, not individual commits, so commits are estimated as pushes ×2. Releases are ranked within accounts that published one, contributors within repository owners, and profile contributions within accounts with any public contribution. Merged pull requests come from the free ClickHouse Playground mirror of GH Archive over Dec 1, 2025 – Feb 28, 2026, the only stretch of the archive that labels merges, and are ranked for windows up to 90 days; the recorded account is whoever performed the merge. The longest streak, once an estimate, is now measured. Lines changed are not in the archive and are never ranked.

Values between cutoffs are interpolated in log-space. When several cutoffs share a value, as small whole numbers often do, the value ranks at the least flattering of them, counted from half a step below: pushing on all 7 days of a 7-day{" "}window ranks Top ~1.5%, not Top ~0.01%. Only positive badges are shown: below Top ~50%, no badge appears. Every percentile display includes “~” to signal these are estimates, and population context names the measured group alongside badges.

Users can click “View the Math” on any analysis result to inspect the exact cutoffs, interpolation, and population estimates for every metric. See the full anchor tables on the methodology page.

5. Caveats as first-class output

Every ShipSleuth analysis includes structured caveats alongside its metrics. These are not footnotes. They are part of the analysis. Key caveats include:

• Private repositories are invisible by default. Users can optionally supplement their analysis with self-reported private activity, but these values are unverified.
• Monorepos and squash merges distort commit counts in both directions.
• Bot activity is detected heuristically and may include false positives or negatives.
• Pagination caps mean very busy repos may be undercounted.
• Public membership lists only show people who have opted in.
• GH Archive counts PushEvents, not individual commits — the ×2 multiplier is an approximation that varies by workflow.
• Merged pull requests are measured over a later stretch (Dec 1, 2025 – Feb 28, 2026) than every other metric.
• Percentile cutoffs come from windows ending May 31, 2025: a dated snapshot, not a live census.
• 19 of the 5-year window's 1,825 days (about 1%) are missing or broken in the archive.
• This is a diligence signal, not a verdict.

6. Design principles

• Honest by default. Surface caveats alongside every metric, not behind a footnote.
• Direct metrics first. Show the underlying numbers rather than a single score; the one overall rank is measured like every other metric and shown only as a rank.
• Non-toxic framing. Percentile badges celebrate high performers without shaming low activity.
• Public signal first. Default to public data. Allow optional self-reported private supplements, clearly labeled and unverified.
• Open source. The entire methodology is inspectable and reproducible.