# A Place for Everything — Zornek's Work-Tracking System

Mike Zornek wrote up the system he uses to track software work when he has the authority to shape a team's workflow. It is specific and opinionated: everything lives in GitHub Issues and Projects, work moves through nine explicit status stages, issues carry a type, and pull requests are written to read like a story. He is careful to frame it as his arrived-at system, not a prescription — when he joins a team with a working process already, he asks questions rather than swapping their flow for his.

## Keep the work next to the code

The core placement decision is to put issues in GitHub Issues and show scheduling through GitHub Projects, as close to the repository as possible. His reasoning is that knowledge about the code should sit next to the code instead of drifting into a separate tool that people forget or abandon — he notes that teams change documentation tools often, and knowledge parked in those tools gets lost in the moves. The second reason is visibility: stakeholders can see what is in flight, track progress on larger epics, and judge schedule risk without asking.

This is the same instinct behind [[filesystem-is-graph-database]] and the "work has somewhere to live" idea in [[jxnl-codex-maxxing]] — put the record where the artifact already is, so the two do not diverge.

## Nine statuses instead of three

Zornek uses more status stages than most boards: Opportunities, On Deck, In Progress, Needs Review, Done (Merged), Deployed (Shipped), To Be Verified, Verified, and Canceled. The extra granularity is the point — at a glance you can tell whether a finished thing is merged, deployed, or actually confirmed correct by a business stakeholder. He separates "merged" from "deployed" from "verified" because those are genuinely different states of doneness, and collapsing them hides where work really sits.

The naming carries weight. He calls the first column **Opportunities** rather than **Backlog** on purpose. A backlog implies a debt you are obligated to burn down; "opportunities" can sit indefinitely, may never be prioritized, and that is fine. It gives an idea a public home for discussion without the standing guilt of a list that only grows. The tradeoff he names openly: the column can bloat until it is unbrowsable, and the fix is to periodically clean it out and close issues. Closing an unprioritized idea is allowed.

That relabeling — choosing a word that changes how you feel about the pile — is the same move [[para-method]] makes by sorting by actionability, and it echoes the "no guilt" framing common to [[basb-overview]]. The name shapes the behavior.

## Types for navigating a long list

Where status answers *where* work is, type answers *what* it is, which matters most when the Opportunities list gets long. His types: Task (including non-code work), Bug, Feature, Enhancement, Enhancement: UI (usability changes with no new behavior), Security, Code Refactor / DevOps, and Documentation. The split between Enhancement and Enhancement: UI is the kind of distinction that only earns its keep once a list is large enough that you want to filter it.

## Pull requests written as stories

Pull requests are where issues actually get resolved, so Zornek ties the two together explicitly. A PR references the issue it closes so the merge closes it automatically, or says `Related to: #123` when the work advances an issue without finishing it.

Three habits carry the weight. Use a PR template, treated as a default rather than a rule — ignore it when a change is better presented another way. Shape the PR as a story: state the problem, walk through the change, explain how it resolves the problem, and give explicit steps to verify it, including seed code when the dev environment lacks the data to demonstrate the scenario. Open PRs early as drafts so others can see what you are working on, and reserve the "open" state and a formal review request for when you actually want eyes on it.

His templates range from a two-line stub (a `Fixes #` line plus a "How to test/verify" section) to a fuller one with Problem Statement, About the Change, How to Test and Verify, and an author checklist. The checklist asks the author to self-review before handing off — is it tested, are the typespecs explicit, did you consider performance, did you document decisions, are there naming changes others should know about, does it need a changelog update, are there follow-up issues worth opening now. He is clear the exact questions matter less than the habit they build: a moment of self-review before a PR becomes someone else's problem. The closing rule is the oldest one — keep PRs small, and learn to break down your changes.

The story-shaped PR is a distillation for the reader's attention, the same respect for a future reader's time that drives [[progressive-summarization]]: do the work of compressing and explaining so the reviewer does not have to reconstruct it.