diff options
| author | Craig Jennings <c@cjennings.net> | 2026-06-28 12:24:59 -0400 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-06-28 12:24:59 -0400 |
| commit | 798ef020f156b52be4703707802779496ed5c859 (patch) | |
| tree | 4a66606e55ac7be804aae653080dbfad33f585dc /docs/design/2026-06-27-bug-priority-matrix-cover-note.org | |
| parent | 9753d03a33aed124cf23573a09dec36695815dde (diff) | |
| download | rulesets-798ef020f156b52be4703707802779496ed5c859.tar.gz rulesets-798ef020f156b52be4703707802779496ed5c859.zip | |
feat(todo-format): make the bug-priority matrix binding for codebases
Any project with a codebase (including home and work) derives its codebase bugs' priority from a severity-by-frequency matrix. The priority is dictated, not argued. The mapping is fixed: P1 to [#A], P2 to [#B], P3 to [#C], P4 to [#D], with the bands defined per codebase. Features keep their roadmap judgment. Privacy, security, and safety defects are graded on severity alone. I preserved the worked-example bundle under docs/design.
Diffstat (limited to 'docs/design/2026-06-27-bug-priority-matrix-cover-note.org')
| -rw-r--r-- | docs/design/2026-06-27-bug-priority-matrix-cover-note.org | 5 |
1 files changed, 5 insertions, 0 deletions
diff --git a/docs/design/2026-06-27-bug-priority-matrix-cover-note.org b/docs/design/2026-06-27-bug-priority-matrix-cover-note.org new file mode 100644 index 0000000..d6398e0 --- /dev/null +++ b/docs/design/2026-06-27-bug-priority-matrix-cover-note.org @@ -0,0 +1,5 @@ +#+TITLE: Cover note for the bug-priority-matrix-proposal.md just sent +#+SOURCE: from emacs-wttrin +#+DATE: 2026-06-27 23:57:30 -0400 + +Cover note for the bug-priority-matrix-proposal.md just sent. WHAT: a Severity × Frequency bug-priority matrix (P1-P4) distilled from wttrin's priority scheme today. It derives a bug's priority from two facts (severity, frequency) instead of opinion, maps each cell to a release vehicle, and — for projects running the todo-format [#A]-[#D] scheme — has bugs derive their letter from the matrix while features keep their roadmap judgment. Includes a special-category rule (privacy/security/safety graded on severity alone) and a tie-in that makes a 'no open [#A]' release gate fact-based. WHY SEND: this is a generic defect-management pattern, not wttrin-specific, so it belongs upstream to distribute with any code-centric project (a claude-rule and/or a todo.org priority-scheme template snippet — your call on placement and whether it folds into todo-format.md or stands alone). TWO ASKS: (1) consider a companion NON-CODING matrix for work-product/ops/decision defects — the same frequency×severity shape likely generalizes beyond bugs; (2) treat this as a LIVING DOCUMENT — adjust bands and wording as projects use it until it's as mature as the coding matrix. SOURCING: the matrix is a standard industry pattern; I adapted a generic version and the wttrin worked-example. Nothing work-confidential is copied — please keep the upstream artifact generic and uncited to any private reference. wttrin keeps its local copy in todo.org as the stopgap until you distribute the canonical. |
