How the contribution ranking is scored

A person's Ranking tab scores them 0–100 against everyone else on the same org tree, blending four 90-day contribution counts by weight. Read it as a conversation starter, not a performance rating — and check for an identity-match gap before you read a low score as low output.

F. Byrne closes tickets every week but reads low — their GitHub login isn't aliased, so PRs and commits count zero.

What it's scoring, and where the counts come from

Counts cover a rolling 90-day window. Each metric is min-max normalized to 0–100 across this tree's people alone — so a metric everyone happens to tie on contributes nothing to anyone's score — then multiplied by its weight and summed. Vacancy placeholders, departed people, and anyone with no matched activity at all are left off the leaderboard entirely rather than shown at 0; opening their card shows "Not ranked" instead of a breakdown.

Reading a person's score

Click a person on the org chart, or their Rating column on an employee board, to open their card's Ranking tab. It shows their rank ("#N of total"), a tier badge — 🏆/🥈/🥉 for the top three, ⭐ "Top 10%", "Top 25%", or a plain rank number for everyone else — and a breakdown table of Metric, Count, Subscore, Weight, and Points, footed by the Composite score.

When a productive engineer reads as idle

The four metrics aren't matched as a set — each contribution row is matched to a person independently, by its own provider. A ticket closes under a Jira assignee name; a commit lands under a GitHub email or login. If one of those doesn't resolve to the right directory record, only the metric it feeds drops to zero — the rest of the score keeps counting. That's the failure mode to watch for: not a blank card, but a plausible-looking low score.

Matching tries, in order: a stored provider alias (a login or email tied to that person); then a provider-agnostic email match (their profile email, or any email alias) — as long as exactly one person on the tree owns that address; then a first-name/last-name match against the activity's display name — again, only if exactly one person on the tree shares that first and last name. Any ambiguity, such as two people who'd both match, is treated as no match at all, on purpose.

1. Open the person's card → Profile → Edit — confirm their Email matches the address their commits, PRs, or reviews actually carry. Email is the strongest fallback signal, and the one field you can correct directly.
2. Check the directory name — if Jira tickets aren't counting, make sure the person's name on the tree matches their Jira display name's first and last token; a mismatched nickname won't match, and two people sharing a first and last name will both silently miss.
3. Sync — click Sync in the tree's toolbar (or Sync now on a Microsoft-connected tree's Source tab) to recompute matched status and ranking counts against the corrected identity.

Under the hood

Ties break deterministically: by composite score, then tickets closed, then PRs merged, then employee id — so re-reading the same underlying counts always produces the same order. Ranking is computed at read time from counts stored on each employee, so it's only as fresh as the tree's last Sync.

If it looks wrong

Related

• Org trees — building the hierarchy the ranking is scored against.
• Employee boards — the Rating column that opens a person's Ranking tab.
• Microsoft Graph — syncing the directory the identity match relies on.
• How metrics are built — the same identity-matching principles applied across Deckgauge's intelligence.

Last updated 17 August 2026