It's funny that a sharable list is such a hotly contested piece of space in the software world.

I admire Trello's desire to keep things simple. I think what you're overlooking is that software is eating the world and if people shy off Trello, who cares. They are not going to run out of customers. We haven't hit a plateau of software projects in the world. And people that trade productive effort against the project for power user fun are probably going to hit a point where the burden of their reporting needs on the project becomes visible to everyone doing the work. (If I sound jaded, blame jira).

Usually power users and their dashboards feed back into projects arcane and fragile rules around how tickets are marked, categorized and written all for the better visibility. I think this is a project anti pattern, it's like the song that plays before the death march.

Generally, I think managers are looking for a magic bullet for complex project management. They are thinking that a some uber reporting and dash board vomiting software package will save them. I know it won't.

I have Visio, but I sure do use WebSequenceDiagrams a lot and enjoy the speed it delivers me with it's focus.

> Generally, I think managers are looking for a magic bullet for complex project management. They are thinking that a some uber reporting and dash board vomiting software package will save them. I know it won't.

Perhaps. But then I feel there's a big hole on the market, something desirable by both individual contributors and product managers. A lightweight ticketing/work planning system that supports certain (arguably fundamental) task management features like:

- Infinite nesting (not just 1 or 2 levels).

- Fast adding of tasks

- Modelling tasks as DAGs, not trees. That is, allowing for proper dependency graph between the tasks.

- Allowing entering both absolute and relative time estimates ("start: 2020-11-01, end: +5 days", and "start: N/A, end: +5 days", where "N/A" means "once all dependencies are complete").

- Turning said task DAG with estimates into a GANTT chart.

- Turning said task DAG into a PERT chart and computing the critical path.

Seriously, the last three are kind of fundamental if you want to do some kind of scheduling around planned work, and yet I haven't seen a single developer-oriented product that could do it. I'm not pulling this list out of my ass - this is what we came up with at my previous job, and we spent time looking for a solution implementing even a subset of this. But for some reason, it's become a religion in our industry that tasks shall form trees, of depth no larger than 2, and GANNT and PERT are for PHB MBAs and not for self-respecting developers. sigh.

If I wasn't a busy parent with a job and a videogame to write, I'd probably write this myself.

What do you mean by infinite nesting here? Provided, the tasks are modelled using DAG.

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.

Seems like one of the better ideas I have seen for a startup.

Wish I had time to do it. The fundamentals aren't really that hard - a dependency DAG of Tasks. Tasks store metadata, including incomplete/relative start/end estimates I mentioned. You could display it as a DAG, or in a traditional "tree structured task" form by just starting at a Task and walking in one direction to fill a tree, and in the other to fill "backlinks". Add a GANTT and PERT chart and that's it.

The most difficult part I think would be to make entering graph nodes ergonomic. In my experience, these kinds of tools live and die by the speed at which you can enter, modify and move things around in them. If you have to click a lot and type data in a bunch of forms, developer won't be using it.

Example: that time when I first compiled the list of desired features, we were trying out YouTrack from JetBrains. My co-worker liked it, but found entering subtasks annoying. I wrote a little script inside YouTrack that turned every Markdown checklist into new tickets, backlinked to the parent one. A total hack, but made a big qualitative difference in terms of working with the tool.

The key two principles for me therefore are:

- Fast to enter and manipulate data in it. Everything doable from keyboard, and little waiting for things to process (hello, Jira).

- Embrace the fact that plans and work subdivisions keep changing all the time. Allow users to restructure their tasks, warn them when they affect other parts of the graph, and just persist the changelog so that a broken graph can be easily fixed.

I have some more ideas in this space, but little time to deal with the surrounding work that's required to turn it into an application prototype.

I really like this idea. I’m going to take a crack at a simple PoC around the data flow and basic UI this long weekend. I’ll chuck it up on my GitHub; I really enjoy working with DAGs (I’m currently building a dynamic form system where groups of form fields are arranged as a DAG to allow for seriously powerful structured data collection and intra-group visibility/validation rules infinitely nested at work)

Glad you like it! I'd love to see what you cook up. I'm noting down to check your GitHub in a few days.

Trello is of a certain vintage. It was a breath of fresh air when launched as it opened up new possibilities from the traditional office tools like docs & spreadsheets. But it's still a purpose-built tool that has a really tight coupling of interface-data, so it's not really a part of the next gen of tools like Airtable or Notion that are data-first and are way more flexible.

I still love Trello for its fantastic info architecture, the card interface, and the data I have in it, but I barely use it anymore because it's not as good at organizing as a database, and not as good at scaling to docs and projects as a tool like Notion.

We've got some stuff up our sleeves...