| Contributor | W. Lines | Commits | C/PR | Lines+ | Lines− | Net | PRs | Reviews | Iteration | Files | Activity (per week) |
|---|
| Contributor | Lines added by package | Top file | Top file lines |
|---|
| File | Commits | Weight |
|---|
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 |
|---|
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".
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 resulting hotspot-weighted sum.
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.
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.
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.
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.
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.
Counts merged PRs that another author later iterated on. A PR is iterated-on if either:
Revert/revert points
at it (an explicit revert), orfix: 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."
.mailmapAuthor 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.