Add epics support

[lyz-code]

Epics are special tasks that help define an abstract goal into more concrete tasks. They are a higher level of abstraction than common tasks and as a result, so tasks can be grouped as subtasks of an epic.

We can reuse the concepts of https://github.com/lyz-code/pydo/issues/37 with something like plan task that opens an editor window where you specify the subtask hierarchy (as many levels as needed), once it closes it creates the tasks and blocks the ones that are not actionable. You can decide to work on the epic (or the parent of all subtasks) or directly on the first available subtask and both will point to the same subtask.

Maybe we can use this notation in the editor parser:

# Epic title: Epic description

* [ ] Task title: Task description
  * [ ] Subtask title: subtask description

Also it's important to define if the tasks at the same level are blocking or parallelizable, so once you mark one as blocked or in review it suggest you to continue with the next available subtask.

For example, we could use the following syntax

* [P] Task title: Task description
  * [ ] paralelizable Subtask title: subtask description
  * [ ] (Blocking) blocking Subtask title: subtask description

You define till what level of task (only epic and tasks?) to define the est, ov, fun attributes, the rest will go plain as they are supposed to be done inside the sprint scope

In the display we could have something like a parent task fulid field.

[xeruf]

Is an epic something completable, or more like an area? For the former, I would advise against an arbitrary distinction of epics, tasks, and subtasks. I wrote about this extensively in https://github.com/GothenburgBitFactory/taskwarrior/issues/2279

[lyz-code]

An epic is a concept I've used while developing under Scrum, the idea (I got) is that an epic is a huge task but that has an end in time. So it's not an area, I feel that projects are the closest resource we have for areas. Areas/projects don't have an end in time, they are ongoing forever.

So epics have helped me while defining the path of action in the long run. Like marking the main working lines of a project.

I've not yet thought of what will mean for a task to be an epic, but probably they'll have their own report and they'll have their own section in the review and planning processes.

What I'm sure is that it will be really easy to upgrade or downgrade a task from epic to task or subtask.

Aside from that, the implementation will probably be an enhancement over the task - subtask relationship, so it will inherit all it's benefits (such as tag inheritance).

Will that cover your concerns?

[xeruf]

Actually, at least in GTD, a project has to be completed at some point. An area is something like "family" or "university", that can easily be represented as tags. A project might be getting a drivers license or moving to a new place.

The thing about projects and epics is that they can easily be represented as parent tasks, since they are also completable. So why create a separate structure instead of allowing tasks to be arbitrarily nested?

• get a drivers license
  • register in a driving school (A) Serial tasks:
  • find close driving schools
  • call driving schools
  • decide on one
  • take all theory lessons (B depends A)
  • get a preliminary driving license (C depends A)
  • learn for theoretical exam (D depends B)
  • take driving lessons (E depends C) ...

All the things you have mentioned could then simply be applied to "root" tasks, I see no need for a special type of task here.

[lyz-code]

I see your point, but find a pair of caveats with your approach.

You can have tags with different meanings. For example, I can use tags to define tasks that are easy to do, or that require low concentration. Or to track what skills get improved after the task completion, such as python or tdd. Thus I find it hard to differentiate the area tags from the rest. And I feel it's important that areas have their own report.

Maybe for the sake of clarity we can rename projects to areas, would that suit you?

Same problem arises when assuming that the "root" task is assumed as an epic. Probably most of the tasks don't have subtasks, cleaning the kitchen will be a root task but not necessarily an epic.

Probably the epic support could be achieved with adding the epic special tag to a task and build a report with that information.

So epics would be the projects in your workflow.

[xeruf]

Yep, adding areas sounds fine.

Does that mean you are also in favor of arbitrary nesting, and instead of epics being a special type it is simply a special tag?

[lyz-code]

Yes, at this point in time I am, regarding task nesting there is it's own issue