Linked Tasks

[MaxSchaefer]

We want to get rid of the current subtasks construct. Right now, a subtask is a (done, string) structure inside a task.

Before we remove the old structure, we introduce a new one.

• A task can have links to next and previous tasks, called linked tasks
• Linked tasks must not result in loops
• Therefore it makes sense to use a "double linked list" as a data structure
• It must be possible to create a task directly anywhere inside the data link structure. For example (T1 -> T3, T2 -> T4). There must be a method to append to T3 directly.
• If a task is marked as completed, this does not affect any other tasks.

Tasks

Preview Give feedback

1. Linked Tasks: Implementation strategy #915
   tasks-svc +1
2. Linked Tasks: gRPC API Design #916
   is-blocked tasks-svc +2

[FoseFx]

What are the exact requirements here? Especially: What kinds of queries do we want to be able to answer?

For example, do we only need direct access to a task's linked tasks, or do we expect frequent transitive access?

I don't think this will matter much for the data-layer representation (an m:n table), but will certainly matter for the internal structure.

---

Linked tasks must not result in loops

Is this a MUST or a SHOULD-level requirement?

---

It must be possible to create a task directly anywhere inside the data link structure. For example (T1 -> T3, T2 -> T4). There must be a method to append to T3 directly.

What does "directly" mean here? How can a task be created (in-)directly?

---

double linked list

most likely not, but that's for #915