Methodology · public formula

How the opportunity score works

A 0–100 ranking that tries to answer “which programs are worth an hour of my time this week”. Three signals, three weights, one linear sum — nothing else, nothing hidden.

The formula

score = payout × 55
      + bounty × 20
      + freshness × 25

Each axis is normalized to 0..1 and multiplied by its weight, so the max possible score is 100.

The three signals

Payout · 55%

log-scale

max_bounty on a natural-log scale between $500 (floor, score 0) and $250,000(ceiling, score 1). Log scale so a $10k program isn’t drowned out by the handful of six-figure whales.

Bounty vs VDP · 20%

binary

+20 if the program actually pays cash, 0if it’s a VDP (recognition-only). A tiny paying program still beats a huge VDP on this axis — because getting paid is a categorical difference, not a gradient.

Freshness · 25%

linear decay 30 → 180 days

Full credit if last_updated_atis within 30 days. Linear decay to zero at 180 days. Everything older, or with no update timestamp at all, gets nothing. A program the platform hasn’t touched in half a year is probably not paying out.

Worked examples

Scenario	Payout	Bounty	Fresh	Score
GitHub-tier · $250k, paying, fresh	55.0	20	25.0	100
Solid · $10k, paying, updated last week	26.5	20	25.0	72
Mid · $2k, paying, ~2 months stale	12.3	20	20.0	52
VDP with big scope but no cash	0.0	0	25.0	25
Dormant · once-paid, half a year cold	20.4	20	0.0	40

What’s not in the score yet

Median response time. Community reports exist but coverage is thin. Adding it now would penalize programs nobody has reported on yet.
Scope breadth. The in_scope_count lives on snapshots, not on the program row. A denormalization pass is needed before this can be sorted at DB level.
Safe-harbor status. Signal is present but too binary at the population level to weight without distorting.

These are v2 candidates. If you’d weight them differently than what’s above, open an issue.

Sort the whole index by this score: /programs?sort=opportunity

source →