Using Linear
"We depend on bottom-up reporting and confidence that teammates will surface issues as they are discovered."
Linear is our project and issue tracking system.
Our Linear instance: linear.app/burnt
Projects
A project is a significant body of work with a clear goal and end state.
Examples: new features, major refactors, integrations, infrastructure upgrades.
Projects should have:
- A clear objective
- A Lead assigned (this person is the Project Lead with decision-making authority)
- A linked Slack channel or thread when the project has an active working group
- Weekly status updates (see Project Updates)
Issues
An issue is a discrete unit of work that can be completed independently.
Examples: bug fixes, small features, technical debt, spikes.
Where issues live:
- Inside a project - Part of a larger body of work. Create directly in the project or use
Shift+Pto move an existing issue. - Team backlog - Standalone work not tied to a project. Can be picked up independently or added to a project later.
Project Statuses
| Status | When to Use |
|---|---|
| Ideas/Feedback | Early concepts, not yet scoped |
| Feature Scoping | Defining requirements and approach |
| Backlog | Scoped but not yet scheduled |
| Planned | Scheduled to start |
| In Progress | Actively being worked on |
| Blocked | Cannot proceed—post an update explaining why |
| External Partner Building | Waiting on external party |
| Completed | Shipped and done |
| Canceled | Will not be completed (see Project Lifecycle) |
Keep status current. Stale statuses erode trust in the system.
Active projects should not sit indefinitely without movement. If work is no longer expected to continue, mark the project Completed or Canceled. If the work may resume but cannot proceed now, mark it Blocked and explain the condition that would unblock it.
Writing Good Issues
Titles - Be specific. Start with a verb. Someone should understand the work from the title alone.
| Bad | Good |
|---|---|
| Fix bug | Fix login redirect loop on mobile Safari |
| Update API | Add rate limiting to public endpoints |
Descriptions - Include context (why is this needed?), acceptance criteria (how do we know it's done?), impacted repositories, and links to related work.
Issues should be clear enough that another engineer or an AI agent can pick them up without reconstructing the original conversation. If important context lives in Slack, a meeting transcript, or a PR discussion, link it or summarize the relevant decision.
TL;DR
- Projects for significant work with a lead
- Issues for discrete tasks (in a project or team backlog)
- Keep status current and clean up stale projects
- Write clear, context-rich issues