GitHub

GitHub exposes a rich set of entity types: pull requests, issues, commits, workflow runs, pull request reviews, releases, and discussions. This integration covers four of these entity types — pull requests, pull request reviews, issues, and workflow runs — which together span the full value chain from code authorship to deployment. Commits and releases were excluded: raw commit counts are the canonical Goodhart trap in engineering measurement, and release frequency, while a DORA metric, is a team-level signal rather than an individual-level one. Seven KPIs were retained across these four entity types, selected against three criteria: ability to attribute to a named owner, resistance to gaming when read in combination, and balance between leading indicators that anticipate problems and lagging indicators that confirm outcomes.

Delivery speed: pull request throughput and code acceptance

PR Cycle Time measures the average elapsed time between the moment a developer opens a pull request and the moment it is merged. This is the engineering equivalent of the commercial sales cycle: the shorter and more consistent it is, the smoother the delivery pipeline. A developer with a persistently long cycle time is a signal worth investigating — it may indicate large, hard-to-review PRs, unclear acceptance criteria, or insufficient reviewer availability.

PR Merge Rate measures the proportion of opened pull requests that ultimately get merged. This indicator is the necessary counterweight to cycle time. Without it, a developer could optimize their cycle time by opening only trivially small changes guaranteed to pass review, or by closing and reopening PRs to reset the clock. A high merge rate confirms that the speed observed in cycle time corresponds to genuinely accepted work, not to gaming of the metric. The two indicators in combination define the shape of a developer's delivery pattern: fast-and-accepted, slow-and-accepted, or fast-but-rejected.

Collaboration health: review participation and responsiveness

Review Turnaround Time measures how quickly a reviewer responds after a pull request is opened. It is the most actionable collaboration metric in this set: a reviewer who is aware of their turnaround time can change their behavior immediately, whereas metrics measuring code quality or architectural decisions require longer feedback loops. When this indicator rises for a specific developer, it becomes a team-level throughput problem: every PR waiting on that reviewer accumulates queue time, which then appears in every author's cycle time.

Reviews Submitted counts the number of reviews a developer participates in as a reviewer. This indicator captures the collaborative dimension of engineering work that cycle time and merge rate cannot see: a developer may ship code efficiently while contributing little to the team's collective review capacity. The Goodhart risk here is real — a reviewer under pressure can submit perfunctory approvals to inflate their count. For this reason, Reviews Submitted is read alongside Review Turnaround Time: a high submission count combined with an unusually short turnaround time is the behavioral signature of rubber-stamp reviewing, and the combination makes it visible.

Issue throughput: task delivery and backlog management

Issues Closed counts the number of GitHub issues resolved per assignee. It is a leading indicator of individual delivery volume when tracked at a weekly cadence, and it captures engineering tasks that do not necessarily produce a pull request — investigations, documentation, configuration changes, and cross-functional coordination. The attribution is robust: issues are created by others (product managers, technical leads, colleagues), so a developer cannot inflate the denominator without external cooperation.

Issue Resolution Time measures the average elapsed time between issue assignment and closure. Paired with Issues Closed, it prevents the most common drift in issue-based measurement: closing issues quickly by marking them done prematurely, or accumulating closures at the end of a sprint. A developer who closes many issues quickly is in a different position than one who closes few issues over long resolution times — but a developer who closes many issues with extremely short resolution times warrants the same scrutiny as one who closes few. The combination of volume and velocity reveals the actual throughput quality.

Pipeline reliability: CI failure rate as a quality proxy

CI Failure Rate measures the proportion of workflow runs that end in failure for a given actor. This is the closest available approximation of DORA's change failure rate at the individual level. A persistently elevated failure rate for a specific developer reveals a pattern — insufficient local test coverage, reliance on CI as the primary testing environment, or repeated integration of under-specified work. It is expressed as a ratio rather than a raw count because raw counts would systematically penalize high-volume contributors: a developer who triggers fifty runs with five failures is in a fundamentally different position than one who triggers five runs with five failures.

The indicator is also a leading signal for team-level delivery risk: when CI Failure Rate rises across multiple developers simultaneously, it suggests an upstream infrastructure or configuration problem rather than individual behavior, and the distinction matters for the management response.

Scope and limits of the integration

GitHub records state transitions and timestamps, but does not measure the quality of the work those transitions represent. A merged pull request may contain a robust, well-reviewed implementation or a shortcut accepted under schedule pressure; the API data does not distinguish between the two. Issue closure does not indicate whether the solution was correct, only that someone marked it closed. CI Failure Rate captures pipeline failures but not the subtler quality problems that pass automated tests — regressions introduced silently, design decisions that create future maintenance burden, or test suites inflated to achieve coverage thresholds.

Attribution also carries a structural limit: GitHub user login resolution to email depends on users having set a public email address on their profile. For teams where members use private emails, the matching process requires maintaining an organization-level login-to-email map. Beyond this technical constraint, GitHub only captures the work that flows through the platform. Informal code reviews, direct collaboration, architecture design, and mentoring remain invisible to this integration. The reliability of these KPIs depends on teams using GitHub as their primary collaboration surface, with consistent issue assignment practices and CI pipeline coverage. Partial or inconsistent use of these features degrades the signal proportionally.