The exact math behind C-Rank™
I built GetMerged because I sent 11 PRs to open-source projects in 2024. Three got reviewed. The rest rotted in backlogs on repos with 40k+ stars. I wanted to know, before I wrote a single line of code, whether the maintainer was actually going to respond.
This page is the answer. Every signal, every step, every safeguard. The scoring module lives in a private repository, but the methodology is fully explained here. If we're wrong, you can see exactly why and dispute it.
The 9 Signals
Every repository is scored on these 9 signals. Each is normalized to 0–100 against the full population, then combined into a single C-Rank score.
External PR Merge Rate
Ratio of merged vs. closed outside-community PRs. Excludes automated dependency bots and internal branch merges.
Normalized against the full repository population. A repo merging a high percentage of external PRs scores higher than one that closes them.
180-day rollingReviewer Response Turnaround
Median time before a human maintainer posts an actionable review on an external PR.
Lower response times score higher. When enough peer data exists, we use percentile ranking. For repos with limited history, we fall back to absolute time benchmarks.
Recent PRsMaintainer Activity Recency
Time since the last merged external PR. A repo with no recent merges is a red flag.
Absolute benchmark scoring: more recent activity yields higher scores. A repo that hasn't merged anything in months drops fast.
180-day lookbackFirst-Timer Contributor Success
Percentage of first-time external contributors whose PR gets merged. Not just opened - merged.
Percentile rank. We detect first-timers via GitHub's first-time contributor flag OR anyone submitting their very first PR to that repo.
180-day rollingTime to Merge
Median hours from PR open to final merge. Fast turnaround without endless rebasing cycles.
Lower is better. Percentile ranking when peers exist, absolute benchmark fallback for lonely repos.
Merged PRs onlyRepeat Contributor Rate
Percentage of external contributors who come back for a second or third PR. The best indicator of a welcoming team.
Percentile rank. If a significant fraction of first-timers return, that's a strong signal.
Past yearReview Cycle Efficiency
Review comment count per merged PR. Rewards clear, consolidated feedback. Penalizes week-long nitpick cycles.
Lower is better. Inverted percentile or absolute benchmarks depending on peer availability.
Per PRMaintainer Team Breadth
Number of distinct active maintainers reviewing PRs. Single-maintainer repos get a safety cap.
Absolute benchmark with a hard ceiling: repos with only one active maintainer cannot reach the top tiers, regardless of other scores.
90-day activeIssue & Discussion Responsiveness
Percentage of external PRs that received at least one human (non-bot) comment or review.
Percentile rank. If a repo never responds to issues, this score is minimal.
180-day rollingHow the Score Is Built
9 steps from raw GitHub data to a C-Rank score and tier. No black boxes.
Collect PRs from the last 180 days
We pull every external PR from the last 180 days via GitHub GraphQL. Bot accounts and internal maintainer PRs are filtered out. Only genuine outside contributions count.
Compute raw metrics
From those PRs we calculate 9 raw values: external merge rate, median time-to-first-response, median time-to-merge, first-timer success rate, repeat contributor rate, review round count, distinct maintainer count, last activity days, and review coverage.
Normalize to 0–100
Each metric is normalized against the full repository population. Time-based metrics reward lower values (faster is better). When a repo has insufficient peer data, we fall back to absolute benchmarks instead of percentile rankings.
Apply the weighted combination
The 9 normalized signals are combined with weights that reflect what matters most to contributors. Merge rate carries the most weight. Response time and activity recency are next. The remaining signals round out the picture. The exact weights are calibrated annually against real PR outcomes and versioned in the scoring module.
Add GFI bonus (capped)
Repos with open good-first-issue labels get a damped bonus. A repo with many beginner-friendly issues scores a modest boost. A repo with none gets nothing. The bonus is capped to prevent gaming.
Shrink towards neutral for low-sample repos
We apply Bayesian shrinkage: repos with very few PRs get pulled toward a neutral midpoint. A repo with 3 PRs gets a heavily discounted score. A repo with 20+ PRs is barely affected. This prevents tiny sample sizes from achieving undeserved top tiers.
Apply staleness cap
If a repo has no meaningful external activity within the lookback window, OR its merge rate has dropped to zero, its score is capped at a maximum and tier is forced to D. A dormant repo is not 'solid.'
Enforce maintainer team safety
Repos with a single active maintainer cannot reach the top tiers, regardless of other scores. Single-maintainer projects are inherently risky for contributors. If that person goes on vacation, your PR sits.
Assign tier with hysteresis
The composite score maps to a tier: S, A, B, C, or D. We apply hysteresis bands to prevent tier flapping from weekly noise. A repo needs to drop meaningfully below a threshold to fall, not just touch it.
Tier Classification
The composite score maps to a tier. Hysteresis bands prevent tier flapping from weekly noise. A repo needs to drop meaningfully below a threshold to fall, not just touch it.
Top 1.6% of open-source projects. High external merge rate, fast reviewer response (p50 ≤ 24h), reliable first-timer onboarding, and active maintainer breadth. This is the open door.
Top ~12% overall. Dependable review cadences, healthy contributor feedback culture, and positive outsider acceptance.
Healthy repositories with active maintainers experiencing periodic triage bottlenecks. Also includes S/A-scoring projects that are safety-capped due to single-maintainer bus factor.
Slow review turnaround or strict maintainer review bars. Best suited for experienced contributors who don't mind multi-week turnaround times.
PR queues with low closure rates, abandoned reviews, or zero external activity in the lookback window. Contributors risk wasting effort here.
Worked Example: How an S-Tier Repo Is Scored
Real numbers from our database. Here is how HeyPuter/puter (43k+ stars) and SubtitleEdit/subtitleedit earn their S-tier ranking.
JavaScript / Cloud Desktop · 753 PRs evaluated in trailing window
Nearly 9 out of 10 external PRs are merged. Tops the 93rd percentile of JavaScript repos.
Over half of brand-new contributors have their initial PR accepted and merged into master.
34 distinct maintainers actively review PRs. Far above the single-maintainer safety cap ceiling.
2.5 × ln(1 + 3) = +3.47 bonus points1 - exp(-753 / 6.0) ≈ 1.00 (Zero shrinkage penalty)Safety Rules That Override Everything
These rules are non-negotiable. They exist because a number without context is dangerous.
Staleness Cap
Repos with no meaningful external activity within the lookback window, OR zero merge rate, are capped at a low maximum score and forced to D-tier. A repo that hasn't merged anything in months is not "solid." It's dormant.
Maintainer Team Safety
Repos with a single active maintainer cannot reach the top tiers, regardless of other scores. Single-maintainer projects are inherently risky for contributors. If that person goes on vacation, your PR sits.
Bayesian Shrinkage
Repos with very few PRs get pulled toward a neutral midpoint. A repo with 3 PRs gets a heavily discounted score. A repo with 20+ PRs is barely affected. This prevents tiny sample sizes from achieving undeserved top tiers.
Low-Sample Flag
Repos with insufficient peer data get percentile metrics collapsed to neutral. The score is still computed, but it's marked with a "low sample" flag and the repo is not eligible for S/A tier.
What We Exclude
Not every repo qualifies. Here's what gets filtered out before scoring begins.
Archived repositories - excluded entirely.
Forks - excluded entirely.
Private repositories - excluded entirely.
Bot accounts - automated PRs and comments are filtered out.
Internal maintainer PRs - only genuine outside contributions count.
PRs older than the lookback window - outside the rolling window.
Repos with insufficient peer data - percentile metrics collapse to neutral; absolute benchmarks are used instead.
Methodology Changelog
We version our scoring parameters. If weights or thresholds change, it gets logged here.
Bayesian shrinkage prior (k = 6.0), bus-factor safety cap (single maintainer ceiling at Tier B), continuous logarithmic GFI curve, and 48-hour human dispute SLA with public recalibration audit logging.
See the methodology in action
Browse 102k repos ranked by C-Rank™. Filter by language, tier, stars, merge rate, first-timer success. Or scan a repo that isn't scored yet.