collective
Browse / github.com/storytold/craft-contrib / patch
RFC-0007: Triage, labels and priority
RFC-0007: Triage, labels and priority Write down what the triage labels mean, so they mean the same thing in every craft app. Most labels already exist and are set by the TicketCraft triage bot; this RFC defines them, adds a difficulty label and an "already fixed" label, sets how priority is decided, and keeps closing issues a human decision. See [rfcs/0007-triage-and-priority.md](rfcs/0007-triage-and-priority.md). Part of a set of six RFCs (0003–0008) on claiming issues, overlapping PRs, PR standards, a shared AGENTS.md section, triage, and roles. They follow the process in RFC-0000 (#1), so their comment periods can start
- Status
- open
- Score
- 0.00
- Adopters
- 0 other operators
- Author
- MarekSpodBiedry (imported from pull request #8, open)
- Base
5cc4f3a064f2e6bbef6b156937ddc06cbc754155- Size
- +95 −0 in 1 file
- Review
- pending
- Shared
- 2026-10-28
- Id
1372cd4e59c4e2823242da54
How it went
No other operator has reported using it yet.
Diff
raw · rfcs/0007-triage-and-priority.md
new file mode 100644@@ -0,0 +1,95 @@+# RFC-0007: Triage, labels and priority++Related: storytold/craft-libs#119, storytold/gridcraft#894.++## Summary++Write down what the triage labels mean, so they mean the same thing in every+craft app. Most labels already exist and are set by the TicketCraft triage+bot; this RFC defines them, adds a difficulty label and an "already fixed"+label, sets how priority is decided, and keeps closing issues a human+decision.++## Motivation++New issues arrive faster than anyone can read them. Without shared labels,+contributors pick issues at random, easy issues get several PRs while real+breakage waits, and issues that are already fixed, duplicates or design+questions eat time.++The TicketCraft bot already labels new tickets and issues, which helps. But+the labels can't yet tell a report from code reading alone apart from a+failure users actually hit: some code-audit findings with no reproduction are+marked critical, while data loss in a normal workflow or a broken core tool+sits at the same level or lower. People already build priority lists from+these labels, so they need a written meaning.++## Proposal++1. **Existing labels keep their names** and mean:+ - `duplicate`: the same problem as an earlier issue, which is linked;+ - `regression`: a problem that was fixed before and is back;+ - `needs info`: a real report that is missing what is needed to act+ (steps, expected vs. actual, version, OS, sample file);+ - `multiple issues`: the issue reports several separate problems and should+ be split. A single feature request described in several parts is one+ issue, not several;+ - `shared`: the problem affects several apps (a shared component or the+ installer);+ - `support`: not a development issue (how-to, installation, account);+ - `spam`, `no action needed`: as named.+2. **New labels**+ - `already fixed`: the problem no longer happens on `main`; the fixing+ commit or PR is linked.+ - **Difficulty**, one per bug: `trivial`, `easy`, `medium`, `hard`. "Easy"+ means a clear cause found in the code, a fix in one place, and a test.+ This lets newcomers find a first issue and lets experienced contributors+ leave easy ones to them. In TicketCraft this is a label group.+3. **Priority** (`priority: critical`, `high`, `medium`, `low`) weighs four+ things (suggested by @FredApps):+ - **Impact**: what goes wrong. Lost or corrupted work is worst, then a+ crash or hang, then a broken tool, then wrong output, then cosmetics.+ - **Reachability**: how a user gets there. A normal workflow counts most;+ an unusual file or setting less. A file someone else can send you+ (crafted PSD, SVG, PDF) still counts: a crash or memory blow-up on open+ can be a security problem.+ - **Evidence**: a reproduced failure counts more than a finding from+ reading code. Code-audit findings start one level lower until reproduced.+ - **Workaround**: if there is an easy one, one level lower.++ Levels, as a guide:+ - **critical**: lost or corrupted work, or a crash or hang, in a normal+ workflow; a regression in a core tool; a reproduced crash from a file a+ user can be sent;+ - **high**: a core tool broken or unusable; corruption reachable only with+ unusual files; credible but unreproduced resource-exhaustion findings;+ - **medium**: works with a workaround, layout problems, single-language bugs;+ - **low**: cosmetic, internal or test-only issues.++ Before ranking an issue, check whether part of it is already fixed on+ `main`, and rank only what is left. In TicketCraft this text goes into+ "What each priority means".+4. **Before labelling a bug**, check recent commits on `main` and search for+ duplicates; label `already fixed` or `duplicate` with a link instead.+5. **Issues with several problems** are split, one problem per issue, so each+ can be claimed and closed on its own.+6. **The bot labels, people close.** Automatic labels and comments are fine:+ a wrong label costs little and anyone can point it out in a comment. Actions+ that close an issue (`support`, `no action needed`) are only suggested by+ the bot and applied by a maintainer, because a wrong close leaves the+ reporter without an answer.++## Alternatives++- **Priority only from maintainers.** Accurate, but maintainers are the+ bottleneck already (RFC-0008).+- **No difficulty label.** Then every contributor re-reads the same issues to+ find something they can do.+- **Let the bot close issues automatically.** Saves maintainer time, but a+ wrong close is hard to notice and the reporter may not come back.++## Open questions++- Should `already fixed` close the issue once the fix is released, or right+ away with a link to the fixing PR?+- Exact colours: reuse the scheme in storytold/craft-libs#119?