Project Management for Bug Tracking

Reported. Triaged. Fixed. Verified.

Most conversations about bug tracking start with schema: fields, severity levels, custom workflows. It's worth starting somewhere smaller instead. What actually happens to one bug, end to end, from the moment someone notices it to the moment someone else confirms it's actually gone?

That path is short and the same every time, whatever tool you're using: reported, triaged, fixed, verified. Where tools differ is whether each step is a real gate or just a status label someone remembers to update. In ShipSprint, each step corresponds to something the board actually does.

The path, one step at a time

Reported. A bug enters through the same triage inbox as any other request. Nobody has to decide in the moment whether this is a "bug" going to one system and a "task" going to another. There's one door, and everything comes through it.

Triaged. Someone decides where it goes: onto a board now, held for later, or merged with something already tracked. It's competing for a spot the same way anything else does, against the column's WIP limit, not against a separate bug quota that exists outside the team's real capacity.

Fixed. On Team plans and above, a branch created against the item moves its card automatically, and merging the pull request closes it. Nobody has to remember to update a status by hand. The board catches up with the code rather than describing it after the fact.

Verified. Someone confirms the fix actually holds. If it doesn't, the card reopens and goes back through triage rather than sitting closed while the bug quietly resurfaces in production, the same honest re-entry any other reopened task gets.

A specific bug, followed through

Say a customer reports that exports silently drop the last row above a certain file size. It comes in through triage, same door as a feature request from a salesperson filed twenty minutes earlier. Whoever triages it decides it's real, decides it matters more than the request next to it, and pulls it onto the board, which means something else in that column, already there, now waits one more cycle. That trade is visible in the moment it happens, not discovered later as an unexplained delay on something else.

An engineer picks it up, creates a branch referencing the item, and the card moves to in-progress on its own, no one has to remember to drag it. Two days later the fix is ready; the pull request merges, and the card closes automatically, because the merge is the actual signal that the work is done, not someone's memory of having finished it. QA, or whoever reported it originally, checks the fix against a real build and marks it verified. If the row still drops under a slightly different condition, the card reopens and goes back through triage exactly like any other piece of unfinished work would.

Nothing about that path required a bug-specific field. Reported, triaged, fixed, verified were all real gates, and every one of them ran through the same mechanism that handles the rest of the workspace.

A production hotfix isn't a special case, either

It's worth naming the scariest version of this directly: a bug found in production, affecting real users, right now. The instinct is to treat it as exempt from every normal rule: skip triage, skip the WIP limit, just fix it. In ShipSprint, that instinct is still allowed to win, but it costs something visible rather than something hidden. Pulling an emergency fix into an already-full column means the team is consciously choosing to exceed the plan for the day, and that choice, and its effect on everything else due that day, shows up in the forecast immediately rather than being quietly absorbed and discovered later as an unexplained delay.

That's a small difference in mechanics and a real difference in honesty. Most teams don't actually mind an emergency jumping the queue. What erodes trust is an emergency jumping the queue silently, so that everything else scheduled that day just seems to vanish for reasons nobody can reconstruct afterward.

What "triaged" is actually deciding

It's tempting to treat triage as a formality: a bug got reported, of course it's real, of course it matters, on to the next step. In practice, triage is the only point in the whole lifecycle where anyone makes an honest call about priority, and skipping it is how low-value bugs end up consuming the same attention as ones that actually cost the business something.

Because the triage inbox holds bug reports alongside everything else headed for the same board, that call gets made in context rather than in isolation. A bug sitting next to a client-requested feature and an internal process fix is being weighed against real alternatives, not evaluated on its own as "a bug, therefore urgent." Some bugs genuinely are the most important thing in the queue. A lot of them, put next to what else is waiting, turn out not to be, and a system that never makes the comparison explicit is a system where every bug quietly acts as though it's the former.

No dedicated bug schema, and why that's the honest choice

To be direct about it: ShipSprint has no bug-tracker object type. There's no severity dropdown, no separate reproduction-steps template, no distinct entity type that behaves differently from a task or a feature request. A bug is a card, full stop, moving through the same board and the same WIP limits as everything else in the workspace.

That's not an oversight we're planning to fix, it's a position. A dedicated bug tracker, kept apart from the delivery board, makes it easy to log a defect and feel like it's handled the moment a ticket exists. What it hides is that fixing the bug still costs an engineer's hours, and those hours were going to go toward something else. Keeping bugs on the same board, competing for the same limited WIP slots as everything else, is what actually forces the trade-off into the open: taking on this fix now means something else waits, and that's visible the moment it happens rather than discovered later as a missed deadline nobody can explain.