agent-orchestrator — Contributor Impact
Combined Leaderboard
| Contributor | W. Lines | Commits | C/PR | Lines+ | Lines− | Net | PRs | Reviews | Rev. Impact | Impact* | Iteration | Streak | Active Wks | Files | Activity (per week) |
|---|
Per-Package Distribution (all-time)
| Contributor | Lines added by package | Top file | Top file lines |
|---|
Standouts
Hotspot Files (top 15 by churn)
| File | Commits | Weight |
|---|
Possible re-implementation pairs
Pairs where a closed PR by author A and a merged PR by author B (B ≠ A) touch a heavily overlapping file set within ±90 days. File-level Jaccard similarity ≥ 50%, both PRs touching ≥ 5 files. Sorted by overlap.
| Closed PR | By | Merged PR | By | File overlap | Shared | Δ days |
|---|
Reasoning & Methodology
Time slicing
Every metric is computed per time slice (all-time / last 30 days / last 7 days). Switch slices via the toggle at the top — the table, stats, and standouts re-render in place. This separates "currently active" from "historically prolific".
Hotspot-weighted lines
A 100-line change to a frequently-edited core file is structurally more important than a 5,000-line change to a generated snapshot or a one-off doc. Each file is assigned a weight (0.5×–2.0×) based on its all-time commit count percentile; high-churn files (the ones the project actually edits often) weight more. The "W. Lines" column is the slice-aware sum: lines added in the selected slice multiplied by the file's all-time hotspot weight. The hotspot weights are intentionally not slice-aware — file importance shouldn't shift just because you switched the toggle.
Reviews as a 4th dimension
Reviews given are a separate signal from reviews received. This column counts reviews on other people's PRs, excluding self-comments and the bots/AI-reviewers configured in the bots list. Senior contributors often shift toward review and away from authoring; without this column, that work is invisible.
Reviewer Impact column
For each PR a contributor reviewed, they earn a depth-weighted share of
the PR's hotspot-weighted impact. Specifically: each reviewer of a PR gets
(their review_weight / sum_of_review_weights) × pr_weighted_total.
review_weight is 1 by default, or
1 + ln(1 + comment_count) when WEIGHT_REVIEWS_BY_DEPTH=1
is set — diminishing-returns boost for substantive reviews.
Composite Impact column
A single rolled-up score: weighted_lines + α · review_impact
with α defaulting to 0.1. Combines authoring and reviewing into one number.
Loses the bias-resistance of orthogonal columns — opt in only if your team
wants a single rank.
Commits and merge strategy (the C/PR column)
The "Commits" column counts post-merge git authors. Squash-merging collapses every PR into one commit (low ratio); rebase- or regular-merging preserves every commit from the PR (high ratio). On the same team for the same kind of work the C/PR column can range from ~0.1 (always squash) to ~10 (rebase or regular merge). High C/PR doesn't mean more work shipped, just a different merge style — read the two columns together. If your team squashes uniformly, "Commits" approximates "PRs" and C/PR sits near 1.0 for everyone.
PRs are credit-weighted
Each merged PR is split across its commit authors by share of additions. A PR whose lines are 80% authored by A and 20% by B counts as 0.8 PRs for A and 0.2 for B. This means the column can show fractional values (e.g. 12.4) when contributors finish each other's branches or pair on a single PR. The goal: opening someone else's branch as your own PR doesn't inflate your number, and contributing meaningfully to someone else's PR shows up in yours.
Optional: similarity-based credit delta
Off by default. When the build is run with SIMILARITY_CREDIT_DELTA=1,
a fraction of each merged PR's credit is shifted to the author of any
earlier closed PR it overlaps with (see "Possible re-implementation pairs"
above). The shift equals the file-set Jaccard, capped at
SIMILARITY_DELTA_CAP (default 0.4) per merged PR. Iteration
attribution does not shift — fixes stay with whoever wrote the
merged code.
Streak and active weeks
"Streak" is the longest run of consecutive ISO weeks within the current
slice where this contributor had any activity (commit, merged PR, or review).
The small "Nw · M now" hint shows the longest run plus the current ongoing
streak ending at this week. "Active Wks" is the absolute count: how many
weeks of the slice's calendar they were present at all, displayed as
active / total. For all-time, total starts at the repo's first
recorded activity.
Optional: reviewer credit delta
Off by default. When REVIEWER_CREDIT_RATE is set above 0
(e.g. 0.05), each non-self reviewer of a merged PR earns that fraction of
the PR's PR-credit and weighted_lines, shifted off the author(s) of the PR.
Capped per-PR at REVIEWER_CREDIT_CAP (default 0.3). Zero-sum;
the totals across contributors stay constant.
WEIGHT_REVIEWS_BY_DEPTH=1 to give heavier
reviews more shift. Long comment threads might be value or friction —
the system can't tell, so the multiplier is logarithmic
(1 + ln(1 + comments)) to bound the effect.
Optional: iteration-based credit delta
Off by default. When the build is run with ITERATION_CREDIT_DELTA=1
(and SHOW_ITERATION=1), each fix-followup that touches an
iterated PR's files takes ITERATION_DELTA_PER_FIX (default 0.1)
of that PR's credit and gives it to the fixer. Total shift on a single PR
is capped at ITERATION_DELTA_CAP (default 0.3) so a hot file
with many follow-up fixes can't drain the original author past 30%.
Strict reverts do not shift credit (a revert undoes work, it doesn't add
value) — only fix:-titled follow-ups do.
Iteration rate
Counts merged PRs that another author later iterated on. A PR is iterated-on if either:
- A later merged PR titled
Revert/revertpoints at it (an explicit revert), or - A later merged PR titled
fix:by a different author, within 30 days, touches at least 2 of its files.
The rate uses credit-weighted PR counts on both sides (a PR with shared authorship splits the iteration the same way as the credit). Rates are hidden for contributors with fewer than 5 credit-weighted PRs.
Revert chains are unwound. If the iterating PR was
itself reverted (or its revert was reverted), the parity is followed back
to whether the change actually landed in HEAD. Iterated only counts when
the iterating change still exists in main. Caveat: this only catches
explicit Revert markers — a hand-rewrite that happens to
restore the original code doesn't leave a git-detectable trail.
Dashboard.tsx or
session-manager.ts will see higher iteration rates than
people working on rarely-edited code, even at identical skill. Read
this column as "how often does the code area you ship in get touched
again soon," not "how often is your work wrong."
Per-author identity dedup via .mailmap
Author identity is normalised through git log --use-mailmap, which reads a
.mailmap file at the repo root. An optional identities file additionally maps
display names to GitHub logins so commits and PRs/reviews join correctly.
What's still missing
- Intra-PR review depth — a "LGTM" review and a 30-comment review both count as 1.
- Code criticality beyond churn — frequency-of-change is a proxy. Files that rarely change but are load-bearing (e.g. a stable parser) are underweighted.