What is a triage decision log?

A brief written record attached to every contentious triage decision: what was decided (priority, assignment, close reason), who decided, why, and when. Routine calls (obvious P1 crashes) don't need entries. Judgment calls (edge cases, closes without fix, deprioritizations) do.

Who writes the triage log?

Whoever makes the final call. The log is a single comment on the bug, not a separate document. It lives with the bug forever in the tracker. New triagers read past entries when they're unsure how to handle a similar case.

When should I NOT log a triage decision?

Routine triage (clear crash is P1, minor typo is P3) doesn't need justification. Log only non-obvious decisions: deprioritizing something that looked critical, closing without fix, reopening an old bug, changing assignment from the obvious owner. The threshold is 'would a new triager be confused why we did this?'.

How to Write a Bug Triage Decision Log

Quick answer: Log only the non-obvious triage decisions directly on the bug: decider, date, reasoning. Routine calls don’t need justification. The log answers “why did we deprioritize this?” three months later and trains new triagers through real examples.

Three months ago your team closed a bug as “won’t fix.” Today a player reports the same issue and your team has to decide whether the old decision still stands. Nobody remembers why. Without a decision log, every contentious triage call re-litigates itself indefinitely.

What to Log

Log only decisions that required judgment. Skip the obvious ones.

Log:

Deprioritizing a bug that looked critical at first read.
Closing without fix (won’t fix, works as intended, duplicate).
Reopening an old bug (what’s different now).
Reassigning away from the obvious owner.
Overriding the priority rubric.

Don’t log: routine priority assignments that match the rubric. A new P1 crash is obviously P1; the rubric justifies it.

The Format

One comment on the bug, not a separate document. Four lines:

Decision: Deprioritize from P1 to P3
Decider: Alex (team lead)
Date: 2026-04-10
Rationale: Only reproduces with a specific NVIDIA driver version
that ships tomorrow. Affected player count < 50 based on telemetry.
Not blocking launch; revisit if affected count grows.

Rationale in a few sentences is enough. The goal is that a teammate reading the bug in 6 months understands the decision without having to dig through Slack.

Why It Matters

It prevents re-litigation. A future triager sees the log and either accepts the past decision or has a specific reason to revisit.

It trains new triagers. New team members read a month of logs to absorb the team’s implicit judgment.

It creates accountability. Decisions with rationale are reviewed for quality; decisions without are lost to time.

It surfaces rubric gaps. If the same rationale appears repeatedly, the rubric should be updated to formalize it.

Quarterly Review

Every quarter, read the last quarter’s decision logs. Look for:

Inconsistencies: same class of bug, different decisions. The rubric needs clarification.
Patterns: the same rationale repeated. Promote it into the rubric.
Mistakes: bugs deprioritized that later caused problems. Learn from them.

Not a Postmortem

Decision logs are written in the moment, not after the fact. A postmortem analyzes an outcome; a decision log records a choice. Both have value; don’t conflate them.

“Decisions without rationale are opinions. Decisions with rationale are accountable. The log is two minutes of writing that saves hours of future debate.”

Related Issues

For broader triage process, see bug triage meeting guide for game teams. For the priority rubric that should back up every decision, see how to build a bug priority rubric.

Read the decision log on any bug older than a month before you change its state. Past context usually changes what the current call should be.