PR churn measures how much code changes after a review — the rework cycle. Unlike review comment density (which measures discussion volume), churn detects actual code modifications that happen in response to feedback.
What Is a Churn Event?
A churn event occurs when the PR author pushes significant code changes after a review. Specifically:
- A reviewer submits a review (approval, changes requested, or comment).
- The PR author subsequently pushes one or more commits.
- The estimated lines changed exceed a dynamic threshold relative to the PR size.
If the estimated changes are below the threshold (e.g., fixing a typo or adjusting formatting), it does not count as churn.
Dynamic Threshold
The churn threshold scales with the size of the pull request:
threshold = max(20 lines, 10% of total PR lines)This means at least 10% of the PR must be reworked to count as churn, with a floor of 20 lines so that trivial fixes on small PRs don’t over-trigger.
| PR Size | Threshold | Effective % |
|---|---|---|
| 50 lines | 20 lines | 40% |
| 200 lines | 20 lines | 10% |
| 500 lines | 50 lines | 10% |
| 2,000 lines | 200 lines | 10% |
| 10,000 lines | 1,000 lines | 10% |
For small PRs the floor dominates, so only genuinely significant rework counts. For larger PRs the percentage takes over, requiring proportionally more changes before flagging churn.
Estimating Lines Changed
GitHub’s PR commits endpoint does not return per-commit line counts. To avoid making extra API calls per PR, CompassHQ estimates:
avg_commit_size = (PR additions + PR deletions) / total_commits
estimated_lines = post_review_commits × avg_commit_sizeThis approximation is reasonable because commit sizes within a PR tend to cluster around the average.
Which Reviews Count
All review types trigger churn detection:
- Peer reviews — the traditional code review
- Self-reviews — the author reviewing their own code
- Bot reviews — automated tools like linters, security scanners, and AI code reviewers
A rework cycle after any review is still rework, regardless of who or what submitted the review.
Only Author Commits Count
When counting post-review commits, CompassHQ only considers commits by the PR author. Commits from co-authors or reviewers (e.g., someone pushing a suggested fix) are not counted as churn, since they don’t represent rework by the original author.
Escalating Severity
Multiple churn events on the same PR indicate repeated rework cycles and score progressively higher:
| Event | Weight | Cumulative Score |
|---|---|---|
| 1st | 1.0 | 1.0 |
| 2nd | 1.4 | 2.4 |
| 3rd | 1.96 | 4.36 |
| 4th | 2.74 | 7.10 |
The formula is weight = 1.4 ^ event_index, where event_index starts at 0. This means a PR that goes through four rounds of rework scores seven times higher than one with a single round — reflecting the compounding cost of repeated review cycles.
Service-Level Metrics
The PR Hygiene dashboard shows three churn metrics for each service:
- Churn Rate — percentage of merged PRs with at least one churn event (the primary metric)
- Avg Churn Score — mean weighted churn score across all merged PRs
- PRs with Churn — count of merged PRs that had churn events
Assessment Levels
| Level | Churn Rate | Interpretation |
|---|---|---|
| Low | Below 20% | Reviews are effective; minimal rework needed |
| Medium | 20–40% | Moderate rework; consider improving PR scoping or review clarity |
| High | Above 40% | Frequent rework cycles; investigate root causes |
How to Reduce Churn
- Write smaller PRs — smaller changes are easier to review correctly the first time
- Add context to PRs — good descriptions, linked issues, and test plans reduce misunderstandings
- Clarify review feedback — specific, actionable comments reduce back-and-forth
- Use draft PRs — get early feedback before the full implementation is done
- Self-review before requesting review — catch obvious issues before peers spend time on them