Issues are durable units of work. Status decides where an issue appears and what it communicates. Projects give related issues a home, a lead, and dates.

​
The issue lifecycle

  1. Capture the outcome and the context needed to check it.
  2. Set properties: project, assignee, priority, effort, labels, due date, visibility.
  3. Plan the issue in chat when the work needs decomposition or research.
  4. Add sub-issues when outputs need independent ownership or status.
  5. Build once scope and destination are clear.
  6. Move the issue through the active states as work changes: Triage, Pending, Planned, In Progress, Review.
  7. Complete it after verifying the expected outcome, or set it to Cancelled.
An issue is Done. A project is Completed. The words do not match across objects; the meanings do.

​
How the views treat status

  • What’s next shows actionable work. Parent issues collapse into their sub-issues, so the view stays honest about what can start now.
  • All and Deliverables show top-level issues, completed ones included. Sub-issues are hidden there; open a parent and read its Sub-issues section, shown as a count such as 0/3.
The full property and view reference lives in Issues.

​
Projects and labels

Use a project for a bounded initiative with a lead and dates. Use labels for classification that cuts across projects: function, risk, platform, customer segment. A project moves through its own status list; see Projects for the current set. Issues carry the day-to-day state, so you usually read progress from the issues, not the project row.

​
Where this shows up

  • Issues: properties, views, and actions in detail.
  • Projects: grouping, labels, and the roadmap.
  • Loop Engineering: why the definition of done in an issue matters.