Module delivery_metrics
Expand description
delivery-metrics analysis — repo-level delivery flow distributions.
Computes six percentile distributions that describe how code moves from
branch to mainline, sliced as percentile-first (p50/p75/p90) summaries
(DORA 2025 convention). The analysis requires the commit_parents table
(schema v4) which records parent revisions and their position; merge
commits are identified as those with a position=1 row.
§Metrics
batch_size_files— distinct paths touched by the branch-side commits bundled into each merge unit. A proxy for PR size.batch_size_loc— totalloc_added + loc_deletedacross the branch-side commits. Complements the file count with raw churn size.branch_duration_hours— wall-clock hours between the earliest branch-side commit’s author-date and the merge commit’s date. Measures how long branches stay open before integration.rework_pct— percentage of added lines that were subsequently deleted or overwritten withinopts.rework_window_dayson the same path. Window is anchored toMAX(date)across all commits so only recent activity is examined. Computed via hunk-pair overlap (approximate — line drift between commits is not tracked). Both sides of the self-join are pre-filtered to the window (bounds the cross-product); the denominator is the total lines added in the window, independent of the pair join.lead_proxy_hours— per-commitdate_diff('hour', author_date, committer_date), positive values only, over non-merge commits. Uses the same author/committer semantics ascrate::analyses::lead_time:commits.dateis the author date;commits.committer_dateis when the commit entered mainline. On squash-merge workflows the delta is small; on merge-via-merge-commit + review workflows it reflects the in-review time.landed_by_other_pct— percentage of non-merge commits wherecommitter_email(case-normalized) differs fromauthor_email: a validated proxy for “someone other than the author landed this” — peer-applied patch, rebase-merge, or bot landing (Rigby & German 2008; later pull-based-development gatekeeper studies). Single-aggregate row (p50 == p75 == p90), mirroringrework_pct’s shape. Caveat:commitscarriesauthor_namebut nocommitter_name, so unlikecanonical_authorthe committer side cannot be mailmap-resolved — a person authoring and landing under two emails they both own registers as a false “gatekept” commit. Not ownership-grade signal; see the row’scaveatfield.
§Squash detection
If the number of merge commits is fewer than 3 AND the total number of
non-merge commits exceeds 50, the repo is likely using a squash or rebase
workflow. The analysis emits a tracing::warn! and still produces rows
with n as-is (branch metrics will be noisy in that case).
§Relationship to existing analyses
crate::analyses::lead_time— per-commit row; this analysis summarises the same signal as percentile distributions.crate::analyses::delivery_friction— per-FILE composite metric (churn × lead-time × cognitive). Complementary, not overlapping: this analysis is repo-level distributions, not per-file scores.
Structs§
- Delivery
Metrics Row - One row in the
delivery-metricsoutput.
Functions§
- run_
delivery_ metrics - Run the
delivery-metricsanalysis against the already-ingested fact store.