About Tasks and Backlogs
A task is one unit of work. There is one task model. Placement decides where that task lives.
A task lives in a section. The section can be:
- the master backlog of the workspace
- the backlog of a project
- a section of a project or of a deliverable
- the inbox of a deployment
The same task is the record in every view. You do not copy it into a calendar or a plan. Other views read it.
The backlog is a section
A backlog holds work that is not committed yet. It is a section with the role backlog. See About Sections.
Each project has one backlog section. The workspace has one master backlog section. The master backlog holds tasks that are not tied to a project.
In a backlog, tasks sort by priority, then by order. Priority is optional. The ladder is urgent, high, medium, no priority, then low.
Backlogs had folders before. Each folder is now a section:
- The folder Main is now the backlog section.
- The folder Queue is now a section with the role queue.
- Each custom folder is now a plain section.
The tasks kept their places. They are in the new sections.
Placement
Capture first. Put new work in a backlog when you do not know its place yet.
Commit later. Move the task into a section of a deliverable when the work becomes part of a delivery. That move commits the task.
A move from a backlog into another section clears the priority. Other moves keep it.
You can move a task to any section, to a project, to a deliverable, or to a deployment. A move to a project puts the task in its backlog section. A move to a deployment puts the task in its inbox. See Move Tasks.
When you make a task with a project and no section, the task goes to the backlog section of that project.
Subtasks
A task can have subtasks. A subtask is a full task: it has a title, a state, an owner, and a description. Subtasks form a tree under their root task. The tree can be at most six levels deep.
A subtask lives where its root task lives. It has the same project, deliverable, and section.
A list of a section shows root tasks only. Each root task shows a count of its subtasks, for example 2/5: two done of five. Open the task to see its tree.
When you move a task, its subtasks move with it. When you delete a task that has subtasks, Ops asks you to confirm first. The delete removes the subtasks too.
Task state
A task is to do, doing, or done. A person can own a task.
The description of a task is Markdown. You read it formatted, and you edit it in the same editor that notepads use.
Comments live on the task, under Updates. Mentions and comments can notify the people who take part. Activity records those changes.
The task page shows the work first: the fields, the description, the subtasks, and the updates. The rare parts and the developer parts, such as commits and attachments, are under More.
When you assign a task, the assignee can get a notification. When a task of yours moves, you can get a notification. You can turn those categories off in settings.
The task map
Each task has a task map. It shows the root of the task and its subtree, its home, its task groups, its lineage, and related tasks. See Read a Task Map.
What other views do with tasks
The map shows tasks inside section rows.
A plan step can link to a task. The step then follows the task state.
A deadline can attach to a task. The date lives on the deadline.
Search finds tasks in the active workspace. You can include completed tasks when you need them.
Strikes are not tasks. A strike is a personal target. Keep shared delivery work on tasks. Use strikes for your own day. See Run Your Day with Strikes.
Why one model
If backlog items and delivery items were two kinds of record, you would copy work as it became real. Copies drift.
One model means a capture in the master backlog can become project work, then deliverable work, without a new record. The graph changes. The task stays.