Change Throughput¶
ContributorsMyles Henaghan
When to use: Deliberately invoke in Agent mode against a git repository to produce a point-in-time read on Lead Time For Changes (LTFC) and Deployment Frequency (DF), plus the contributor mix behind them. Re-run periodically (e.g. monthly) to track delivery throughput and set or check a per-active-contributor benchmark.
Instructions¶
- Read references/change-throughput-prompt.md and follow the scope gate before any history commands.
- Prefer the bundled scripts under scripts/ — stdlib only; no network and no writes to the target repo unless the user asks to save the report.
- Run the unit tests before trusting engine output:
python -m unittest test_metrics.pyfromscripts/. - Confirm the deploy trigger: merge frequency is DF only when a merge to the trunk deploys. Otherwise relabel as integration frequency.
- Write the report as a single markdown document. If asked to save it, use
docs/change-throughput-YYYY-MM.mdin the target repo.
What this diagnostic covers¶
| View | What it answers |
|---|---|
| Throughput | LTFC (first commit → merge to trunk) and DF (merges per week / work-day), split into meaningful vs micro changes |
| Contributor mix | Who is genuinely active vs occasional; concentration / bus-factor |
| Benchmark check | Actual vs 1 good change per N active contributors per work-day (default N=2) |
References¶
Troubleshooting¶
| Symptom | Likely cause | Fix |
|---|---|---|
| Zero PRs in window | Host does not write pull request #N merge subjects |
Enumerate merges another way or widen subject matching |
| Inflated contributor count | Same person under multiple git identities | Extend AUTHOR_ALIASES in metrics.py for the target project |
| DF mislabelled | Merges do not deploy | Relabel as integration frequency; note the real deploy gate |
| Distorted LTFC | History rewriting | Check author vs committer dates; flag rebase/squash risk |