DevGovernance

Sources. The commit log for each repo\u2019s default branch plus the head branch of every open pull request, in the visible period (deduplicated by commit SHA), matched to contributors by GitHub login · line counts from GitHub’s weekly contributor statistics (the REST commit list omits them, and GitHub’s GraphQL API cannot be called from a browser) · open PRs from the pull-request API. With “use commit log” unticked, figures come instead from GitHub’s weekly statistics, which only cover each repo’s default branch.
Metrics. Active days/wk = distinct calendar days with ≥1 commit ÷ weeks in period. Weeks active = share of weeks with ≥1 commit. Commits/active day = matched commits ÷ active days. Lines/wk = lines added + deleted ÷ weeks. Longest gap = most consecutive days without a commit. Open PRs = pull requests currently open that they authored.
Verdict thresholds. Consistent with full-time: ≥3.5 days/wk and ≥75% of weeks active. Mostly full-time: ≥2.5 days/wk and ≥60% weeks. Bursty but delivering: below those rhythms, but lines/wk at or above the team median (floor 200) — work is batched into few, large pushes. Part-time signal: ≥1.2 days/wk. Well below full-time: under that. Too little data: fewer than 3 matched commits. Couldn’t match commits: weekly stats show activity but nothing matched in the commit log — usually an unlinked git email.
Blind spots — read before acting. Code review, pairing, meetings, design, incident response and unmerged feature branches leave no trace here; squash merges compress days of work into one commit; line counts can be inflated by lockfiles, generated code or reformatting. Open PRs are surfaced precisely because in-review work is otherwise invisible. A weak signal is a question to ask, never a conclusion.