Not infinite-infinite, just with no obvious limit. If task depth was maxed out at 256 levels, I probably would never notice.
Most systems I've seen allow you a one top-level of Task (under some "project", "epic" or whatnot). Then you can - in some - add a kind of degenerated, impotent Subtask to that task. And then your next level of nesting is just a humble bullet-point checklist.
What I want is truly composable Tasks. Because sometimes real-world work expands like that. Because I want to subdivide my work within the ticket I'm assigned to. Because sometimes I don't know how much the entire ticket will take, but I have a pretty good estimate on what the subtasks will take, so I want to input that, and then both me and my manager will have a ticket estimate that's a little bit less nonsense.
The DAG part enters the picture here: I want to be able to have tasks depend on each other. I want to be able to make a top-level ticket depend on a sub-sub item of another ticket, because sometimes your co-worker can start working on their part once you do one small part of yours, and it would be nice to have that information correctly recorded in the system (instead of Task B being blocked by the entire Task A).
(I talked about nesting before, but the truth is, with a DAG, nesting stops being a first-class concept. It's just a matter of presentation, of which you could offer many types - but underneath, it's all just a graph of tasks that connect to each other. A simple and elegant model.)
Now I know that there's a lot of software "agile" philosophy that essentially makes you implement that DAG in your head. No point of cross-subtask dependencies if your agile dogma tells you tasks need to be small. No point in complex linking if half of it won't fit in a sprint, etc. But that's using philosophy as a hack around inadequate tooling.
There comes a time in a team's life where you want to plan out some complex work that spans multiple stories/epics/whatnot. Many months. Tooling for that is scarce (and this is how we discovered the desired features I listed in the previous comment). But I see no reason why you should do that work on a different tool than the one you'll be using for day-to-day work. Imagine instead that, during a planning session, you subdivide work as deep and wide as you can, you link it all into a dependency DAG, enter initial estimates, etc. Then, day-to-day, people will adjust and subdivide and relink nodes as the work demands, but at all times, the entire plan, the entire schedule, and the critical path, is visible to everyone.
That's what I want. A ticketing system that also works for project planning, locking day-to-day work and planning into a tight feedback loop - so that you have both high and low-level views available, and always in sync.
>with a DAG, nesting stops being a first-class concept
This is what I was wondering about. Please correct me if am wrong. If tasks are indeed modeled using a DAG, then there is essentially no nesting, right? What we think of nesting in the traditional sense can just a bunch of small tasks with varying dependancies.
Yes and no. A DAG eliminates nesting as a concept, but you can, and probably[0] should, still reintroduce it. There is a meaningful difference between tasks that are conceptual subcomponents of another, vs. tasks that merely depend on another. This could be reflected by different labels/colors of DAG edges (e.g. :depends-on vs. :component-of), and could be appropriately visualized in GUI.
The metaphor of nesting is a solid one - tree structure does capture a good subset of thoughts about task management. So I'd start with a proper tree of subtasks, not limited by depth[1], and then add the ability to link any other task as a dependency (as long as no cycle is formed).
You could expand the types of edges[2] to allow things like "optional dependency" or "starts when dependant task starts" to model parallel work. But I'd begin with just augmenting a tree with backlinks and surfacing the graph structure. And then providing GANTT charts and PERT analysis. I really do want to have the critical path be always computed and evident to the team, as well as available slack on each task.
--
[0] - I haven't seen a tool like that nor do I have working prototypes, so I'm all playing it out in my head.
[1] - I currently have such proper tree in Org Mode - and my tasklists tend to routinely grow 3-4 levels deep.
[2] - Instead of edge types, you could use node groups. Like, have "Task 3.a.1" represented as "Start of Task 3.a.1" -> [subtasks of 3.a.1] -> "End of Task 3.a.1", but multiple edge types are likely to be much easier to work with.
