> ## Documentation Index
> Fetch the complete documentation index at: https://mehen.ophi.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Bug risk

> Bug-fixing commit count and Google's Time-Weighted Risk — where fixes keep landing.

Where bugs were fixed before is where bugs tend to appear again. mehen ships the two transparent
forms of this signal from Google's bug-prediction study: a plain **bug-fix commit count** (the
"Rahman algorithm" — which Google's developers preferred for its transparency, and which performed
nearly as well as anything fancier) and **Time-Weighted Risk (TWR)**, which weights each fix by how
recently it happened so that a file's ancient sins eventually stop counting against it.

## What mehen emits

| Key                      | Type  | Description                                                                                                                                                                                   |
| ------------------------ | ----- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `history.bugfix_commits` | int   | Commits touching the file whose message matches the bug-fix heuristic.                                                                                                                        |
| `history.twr`            | float | `Σᵢ 1 / (1 + e^(−12·tᵢ + 12))` over the file's bug-fixing commits, where `tᵢ` is each fix's time normalized to `[0, 1]` across the walked history (0 = oldest commit, 1 = analyzed revision). |

A fix at the analyzed revision contributes \~0.5; a fix at the start of history contributes
effectively zero (\~e⁻¹²). TWR is quantized to 10⁻⁹ before publication so that identical
repositories produce bit-identical values across platforms.

## The bug-fix heuristic

TWR's honest weakness (acknowledged in the primary source) is that "bug-fixing commit" needs a
definition. mehen uses a transparent whole-word match on the commit message: `fix`, `fixes`,
`fixed`, `fixing`, `fixup`, `hotfix`, `bugfix`, `bug`, `bugs`. Word-boundary matching keeps
`prefix` and `debugging` from counting; issue references like `#123` are deliberately **not**
treated as bug markers, because on GitHub-style squash merges every PR commit carries one.

## How to read it

| Signal                          | Interpretation                                                                                     |
| ------------------------------- | -------------------------------------------------------------------------------------------------- |
| High `bugfix_commits`, high TWR | Fixes keep landing here *recently* — the strongest "this file will bite again" signal.             |
| High `bugfix_commits`, low TWR  | A formerly buggy file that has been quiet — probably rehabilitated.                                |
| Rising TWR in a diff            | The change touches a file in an active bug-fixing phase; extra review scrutiny is cheap insurance. |

Present this signal modestly: Google's own deployment of TWR produced no significant change in
developer behavior. It is a review-attention hint, not a verdict.

## References

* Lewis, C., Lin, Z., Sadowski, C., Zhu, X., Ou, R. & Whitehead Jr., E. J. (2013). *Does Bug
  Prediction Support Human Developers? Findings from a Google Case Study.* ICSE 2013.
  [PDF](https://users.soe.ucsc.edu/~ejw/papers/lewis-icse-2013.pdf).
* Rahman, F., Posnett, D., Hindle, A., Barr, E. & Devanbu, P. (2011). *BugCache for inspections:
  hit or miss?* ESEC/FSE 2011 — the frequency-ranking baseline.

## See also

* [Commit frequency](/metrics/history/commit-frequency) — all commits, not just fixes.
* [Code age](/metrics/history/age) — general recency, without the bug-fix filter.