You open the issue board on a Monday morning and there are 212 open items. Forty of them say "crash". Six of those forty are the same crash, filed by four different people, two of whom used the word "freeze" instead. Eleven are from a build that shipped three weeks ago and may well be fixed already. Nobody knows, because nobody has read the board end to end since May.
This is what happens to a bug list without triage. It isn't a list any more — it's a landfill. And the failure mode isn't that you ship a buggy game. It's that you ship a game with the wrong bugs fixed, because the loudest report got attention and the save-corruption issue sat behind a typo in the options menu.
Triage is the cheapest process in game production. Forty minutes a week is the difference between a backlog that shrinks and one that quietly decides your launch date for you.
Start with an intake contract
Most triage pain is intake pain. A report that arrives incomplete costs someone twenty minutes of chasing before the work can even be scheduled, and that cost is paid every single time the report is looked at.
Agree on the minimum a bug report must contain before it is allowed into the board:
- Build number. Not "the latest build". The actual identifier —
0.7.3-win-4412. A report without one is untestable, because you can't tell whether it's already fixed. - Platform and configuration. OS, GPU, controller vs keyboard, resolution, language. The bugs that only appear in German at 1280×720 on a Steam Deck are real and they are the ones you find last.
- Steps to reproduce, numbered. Three to eight steps. If the reporter can't write them, that itself is data — log it as repro-rate unknown.
- Expected vs actual. One line each. This is where you discover that many "bugs" are disagreements about design intent.
- Frequency. Always / often / sometimes / once. An always-repro crash and a once-in-forty-hours crash are not the same work item.
- Attachments. Save file, log file, short clip. A save file that reproduces a bug is worth more than a paragraph describing it.
Put this in the bug template itself so it's filled in by default rather than remembered. If you're tracking issues in the GameDesignerX issue log, the fields sit on the entry, which means the build number and repro rate are filterable later instead of buried in prose.
One more rule worth enforcing: one bug per report. A ticket titled "various UI problems" cannot be closed, only abandoned.
Severity and priority are two different columns
The single most common triage mistake is collapsing these into one field. They answer different questions.
Severity is about damage, and it's close to objective. Anyone can assign it.
| Level | Meaning | Example |
|---|---|---|
| S1 | Progress loss or hard block | Save corrupts; boss fight can't be completed; game won't launch on a supported GPU |
| S2 | Major feature broken, workaround exists | Quest marker points to the wrong room; audio drops after alt-tab and returns on reload |
| S3 | Noticeable but survivable | Enemy T-poses on death; tooltip shows a placeholder string |
| S4 | Cosmetic or trivial | Two-pixel gap in the inventory border |
Priority is about scheduling, and it's a judgement call the whole team makes together. It combines severity with how many players will hit this and how expensive is the fix.
A polish issue in the first two minutes of the game can outrank an S2 in an optional side area, because every player sees the opening and only some reach the side area. Say that calculation out loud in the meeting rather than assuming everyone shares it.
A workable default: priority = severity, bumped one level up if it's on the critical path through the game, one level down if it's behind an optional gate.
Run the meeting in twenty minutes, twice a week
Triage is not a bug-fixing meeting. Nobody debugs anything in the room. The only outputs are severity, priority, owner and target milestone.
Three people is enough — someone who knows the code, someone who knows the design intent, someone who runs the board. Work through everything filed since last time, in filing order, giving each item one of five verdicts:
- Accept — severity, priority, owner, milestone. Done, next.
- Duplicate — link to the original, close. Keep the better-written report as the canonical one, not necessarily the first one filed.
- Needs info — bounce it back with the specific missing field named. Set a deadline; if it goes stale for two weeks with no response, close it.
- Not a bug, it's a design question — this is the important one. Route it to your decision log instead of the bug board. "Stamina drains too fast in water" is not a defect; it's a balance argument, and it will rot on a bug board forever because no engineer can close it.
- Won't fix — say why, in one sentence, in the ticket. Future-you will re-file it otherwise.
If an item takes more than ninety seconds, it's a "needs info" or a design question in disguise. Move on.
Give bugs a lifecycle, and tie "fixed" to a build
A bug is not fixed when a programmer says it is. It's fixed when someone else can't reproduce it in a build you can name.
New → Triaged → In progress → Fixed in build X → Verified → Closed
↓
Reopened (still repros in X)
The "fixed in build X" state is what makes the whole thing work. It lets you clear the board fast after every build: filter for everything marked fixed in builds up to the one you just made, hand the list to whoever is verifying, and close in batches. Without a build number on the fix, verification becomes archaeology.
This is where build tracking pays for itself. If each build in your tracker carries its number, date and the list of issues marked fixed in it, your release notes and your verification queue are the same artifact — generated, not written.
Two states people forget to define: Cannot reproduce (three attempts in the current build on the reported configuration — if it comes back, it reopens with new repro steps) and Deferred (real, accepted, not this milestone — with a milestone named, or it just means "never").
Watch the two numbers that predict your launch
You don't need a dashboard. You need two counts per week: bugs opened and bugs closed.
If closed is consistently higher than opened, you're converging and you can estimate a date. If opened is higher, you're diverging, and overtime won't fix that — you are generating defects faster than you retire them, which usually means an unstable system needs rework rather than patching, or your content push is outrunning your QA.
Plot both weekly on one chart. The crossover is the most honest release-date estimate in your production.
Tighten the bar as you approach ship
Late in a project, the danger isn't unfixed bugs — it's fixes that create new ones. So change the rule, deliberately and on a named date:
- Milestone minus 8 weeks: fix anything S1–S3, polish freely.
- Minus 4 weeks: S1 and S2 only. S3 and S4 go to a post-launch list — which you actually keep, because it's your first patch.
- Minus 1 week: S1 only, and every fix needs a second pair of eyes plus a named regression test. "It's a one-line change" is how a shipped build loses its save system.
Write those dates down before you're emotional about them. Deciding a bug bar during crunch, with the bug in front of you, never goes well.
The twelve-line checklist
- Bug template enforces build number, platform, repro steps, expected/actual, frequency
- One bug per report
- Severity (S1–S4) defined in writing, with an example for each
- Priority is a separate field, set by the group
- Triage runs twice a week, timeboxed to twenty minutes
- Every item leaves triage with an owner and a milestone
- Design disagreements are routed out of the bug board
- Duplicates are linked, not silently closed
- Fixes are marked with the build number that contains them
- Verification is done by someone other than the fixer
- Opened-vs-closed counts reviewed weekly
- Bug bar dates set in advance and honoured
None of this is glamorous, and none of it will appear in your trailer. But a backlog you trust is a backlog you can plan against — and planning against a real number is the whole job in the last third of a project.