Work tracking in Linear

How work is organised in Linear

Basic philosophy

An issue reaches the roadmap only through a project, and a project only through an initiative.

Initiatives answer one question: which surface does this work belong to?

Initiatives

Initiative	What it covers	Test for "does this belong here"
Inference	Serverless proxy to third-party models plus Iris, our own serving stack. Provider routing, model catalogue, API surface.	Does a customer hit it with an API key to get tokens back?
VMs	The fulfilment path. Everything between a customer asking for a GPU and them having SSH. Hydra, provider selection, the autoscaler, spot.	Is it about handing someone a machine?
Serverless GPU	Job execution. Python, a Docker image, or docker-compose submitted via API or CLI. Containerise, schedule, run, stream output.	Is it a job that starts and finishes?
Clusters	Turning raw bare metal into usable capacity. Orchestration, multi-tenant isolation, InfiniBand and RDMA, images.	Is it about hardware we own, before Atlas can list it?
Atlas	Knowing what infrastructure we have, where it is, how utilised it is, and making it available to Hydra.	Is it "what do we own, and can Hydra allocate from it"?
Admin	Organizations, accounts, billing, auth, and anything administrative that belongs to no compute surface. Croesus metering.	Would this exist even if we sold something other than GPUs?
UX	How the product feels to use. Dashboard and API both, because developer experience is user experience.	Is the problem that someone cannot get their work done, rather than that something is broken?
Tooling	Internal tooling and engineering infrastructure. Work our own team needs that no customer will ever request.	Would a customer ever ask for this? If no, it belongs here.
Commercial	Customer-facing but not the product. CRM and attribution, compliance certifications, pricing, demand intake.	Is it about selling and proving, rather than building?

Bugs and debt projects

Each initiative owns one standing project named <Initiative> bugs and debt, the home for defects and debt outside planned work.

State stays In Progress. It never completes.
No target date, no lead required.
No Primitive or Feature label.

These projects read as In Progress at 0% forever. That is expected. Exclude them from health and progress views.

Moving work around

Don't move an issue into someone else's live project. Add it to that project's description under a Candidate issues heading. The lead pulls it in.
Move projects between teams, never issues. A project can belong to several teams, so add the team to the project.
One project per issue. Work spanning two projects becomes sub-issues, one per project.

Danger

Moving an issue to another team generates a new issue ID and URL, strips the project association, and remaps the status. Branch names are derived from issue IDs, so existing branches and open PRs no longer match.

Keeping the roadmap honest

Hunt for these states. Each one makes the roadmap lie:

Completed project with open issues: reopen it or rehome the issues.
In Progress project with no issues and no lead: move it back to Backlog.
Target date on a project with no lead: staff it or remove the date.
Cancelled project with a linked customer need: record the decision, don't cancel as cleanup.