📘 The tale of Jerod the unwise in the subtask maze

[Bastien_Siebman]

I think my biggest question remains: is this considered broken, or just the way subtasks are meant to be. For example, multiple assignees on a task isn’t broken, it isn’t a missing feature, it is simply a choice. Not completing a parent task when all subtasks are completed → to me that’s a choice, and I truly hope this is never implemented for example

[Sarah_L]

I’d suggest it’s a bit of both.

Related to if a subtask is homed in a parent’s project - I think something is bundled up too much here:

1. Where the subtask ‘lives’
2. Where the subtask is visible

I can see it being logical that a subtask lives in any/all of the projects that their parent task lives in.

I can see it being ideal if that subtask (at whatever level) doesn’t appear in the project list view in the same way a main task does, unless you specifically want it to.

I can see it being ideal (and I use it a lot right now) to make it possible to make a specific subtask appear in a project’s list view (e.g. when you want more visibility of that particular subtask).

I could see it being more complicated to think through use cases where a subtask inherits its parent’s project, is added to another specific project, but then the parent task is moved to a different project - you’d want the inherited project to be updated but not the specific one removed (i.e. you added visibility at the main task level for that project).

One is about where it belongs, and one is about where it displays.

The problem with viewing that subtask by itself in a list view (My Tasks, Search Results, Tags, etc) is that it doesn’t belong anywhere (unless specifically added to a project).

Interestingly, when you view My Tasks and you have that long list of subtasks in the “No Project” section - the projects column DOES show the parent’s project. But it is still “No Project” within My Tasks. At least this part sounds broken, no?

My ideal would be if My Tasks (and other places) recognised/grouped the subtask with the same project the task’s parent is in, plus indented it or added some amount of grey prefix > symbols (for example) just to indicate that this is a subtask and not a task. Hover over the symbol to see the parent task name. Click on the symbol to open the parent. The interface is kept quite clean, but there’s much more at-a-glance clarity about the depth of this ‘task’ while still having it appear in My Tasks/Search Results/Tags as a task ‘row.’

(I know the end of the task name you’d see the grey parent task name. Some task names are long though, so you can’t tell - like in my screenshot. And it doesn’t show the depth of nesting.)

But the minimum ask is recognising the task is ‘in’ a project when grouping any list by project.

[Bastien_Siebman]

I cleaned up the post a bit. Not a lot of new things, but we know a lot is coming around subtasks!

[Garrett_Knoll]

Buckle up! Subtasks are a priority and we’ll be iteratively overhauling them over the next 6+ months via many phases of releases. If you’re interested in previewing and sharing feedback, react to this message so we know to reach out to you to start testing in the next month or so! Big thanks to @Bastien_Siebman for spending so much time with me and my team to help shape our Subtask roadmap

[Bastien_Siebman]

Amazing, thanks for the shout out. Am I allowed to create t-shirts that say “I helped fix sub-tasks”? Do you want one, Garrett?

[Garrett_Knoll]

@Bastien_Siebman subtasks are the mountain I continue to die on and continue to convince our leadership of. We all need subtask t-shirts - but I think I should send you all them once we ship them shortly. Asana owes you all that

[Bastien_Siebman]

@Garrett_Knoll

but I think I should send you all them once we ship them shortly. Asana owes you all that

That’s a deal

[Arthur_BEGOU]

@Garrett_Knoll