[Discussion] What is a parent task? Is it a real task, is it a container?

[Djo]

I've finally found some main reasons why I struggle with parent tasks in ToDoList.

This is a big topic, it involves design aspects now probably deeply rooted in the software, so probably difficult to change now. So, as far as I love the program, I'm going to be critical of certain aspects of it. I'm not going to post suggestions about this (unless Abstr asks me to) because the subject has many facets and is complicated to define properly.

By looking at the treatment of 'parent tasks' in several other programs, the common way to consider them can be summarize as this: the parent task takes on the form of a summary task or rollup task for its child tasks
https://docs.servicenow.com/en-US/bundl ... ships.html

https://docs.oracle.com/en/cloud/saas/n ... 99176.html
Parent task records track the following data sourced from its subordinates:
- Start Date – the earliest start date of all subordinate tasks
- End Date – the latest end date of all subordinate tasks
- Estimated Work – the cumulative total estimated work for all subordinate tasks
- Actual Work – the cumulative total actual work done for all subordinate tasks
- Remaining Work – the cumulative total work remaining for all subordinate tasks
- Percent Complete – the percentage of work completed for the task overall

This was the trigger for my understanding of my problems with parent tasks, and now I wish the program would consider parent tasks exactly like this: a summary task or rollup task. So, with most of the attributes of the parent tasks calculated from the subtasks.

For example, it makes no sense IMO that the start and due dates of a parent task are not dependent of the subtasks. As quoted above:
- the parent start date: the earliest start date of all subordinate tasks
- the parent due date: the latest end date of all subordinate tasks
(although changes could possibly be allowed directly on the parent's dates)

Another example: the attribute 'Category' of the parent task would summarize all the categories defined on the subtasks (although adding categories could probably be allowed directly on the parent task too)
Same for the 'Allocated to' attribute, etc.

In fact, the way each attribute is summarized (or not) at the parent task level should be defined. A summary of a given attribute from the subtasks can indeed take one of these forms:
- the set of all values used
- the most frequent value
- the sum of the values
- the number of occurrences
- the maximum (or minimum) value
- other rules (see about statuses below)
- etc.

In the current implementation, only a few attributes ('Last modified', 'Flagged', 'Completion status', '% completion', Time Spent, 'Time Estimate') can be calculated from the subtasks.
For all the other attributes, it's the subtasks that can inherit the attribute value from their parent. This inheritance can be handy at some moments for some attributes (eg. at the subtask creation), but doesn't really make sense afterwards for quite a few attributes, and for dates and status.
Apply the start and/or due date of parent task to all its subtasks doesn't really make sense within the framework of a project. Each subtask have different start and due dates. Again, it should be the opposite: the dates of the parent task calculated from the subtasks.

The management of the 'Status' attribute also annoys me in the program. Consider this simple task break down:
-ParentTask1 (status: todo)
--Subtask1.1 (status: todo)
--Subtask1.2 (status: todo)

Now if the status of 'Subtask1.1' is changed for 'In progress', I wish the 'ParentTask1' status to be changed automatically to 'In progress' too. So here again, that the status of the parent task summarizes the different statuses of the subtasks.
This would imply to define calculation rules between statuses, in order to display the most relevant status at the parent task level.
For example: Subtask1.1 is 'Completed' and Subtask1.2 is 'Todo' = 'ParentTask1' is 'In progress'. (source of the example: http://www.centriqs.com/manuals/83217-h ... btasks.php)

So, here again, statuses of the subtasks and status of the parent are not in sync currently (at least in the most useful direction subtasks > parent). So the management of statuses between the parents and the subtasks is manual at best, and it is very confusing for the user to find the right workflow because of that (at least it was for me).

So each parent task would be a summary of the subtasks it contains, so even when collapsed an overview of its content would still be displayed, and up to date because in sync. That would be very useful, and what is expected, I think, with parent tasks.

Now I'm going to anticipate an objection that can be made: "it may well suit YOUR workflow, but it won't work for everyone. Some people use parent tasks differently."
To this I would reply that this is how parent tasks work, I guess, in virtually all softwares but ToDoList. That there is a logical problem that the start date of the parent task is later than the date of one of its subtasks, that the status of the parent is 'To Do' but on of its subtasks is 'In progress', just to pick two examples. These strange and incoherent possibilities offered by the program (the parent not in sync with its subtasks) doesn't offer any additional useful flexibility IMO, just a lot of confusion, difficulties to set a proper workflow, and finally some additional manual work to do (to keep the attributes in sync).

The fact that the main statuses of a task are not 'hard coded' but it's up to the user to make the list himself can also appear to be a problem, because this seems to make the automatic management of the statuses by the program (based on dates or other criteria) less possible.

Well, now I'm glad I did realized that, it will help me manage better the tasks with parents. Even if the program doesn't do it automatically the right way for me.

I'm now interested to know what YOU ALL think of all of this, and of course especially Abstr, even if I understand that the subject is rather too massive and indigestible!

[Ryan]

For example, it makes no sense IMO that the start and due dates of a parent task are not dependent of the subtasks. As quoted above:
- the parent start date: the earliest start date of all subordinate tasks
- the parent due date: the latest end date of all subordinate tasks
(although changes could possibly be allowed directly on the parent's dates)

I only had time to read part of this post and it was interesting. This concept you talk about in the post does indeed sound like it might be related to why I have expressed some confusion about the hierarchy in TDL. I will come back when I have more time to read the rest.

If you addressed this in the post in the part I didn't get to I apologize. But this example is covered in TDL.

[Djo]

Thanks Ryan, I completely missed this option on dates! I'd been set it on 'Its assigned date'. I set it up right away and will see how it behaves.

I reread my post and now it has less scope. I'm well aware that already a number of attributes can be calculated from the subtasks. The point is to extend this possibility to most of the attributes, and probably even the custom attributes.

The other point of my post is to share my feelings about the complexity to set up a practicable workflow in ToDoList because the program leaves so many options open, and "open to all winds". The 'Attribute Calculations' tab is quite indigestible and could be probably be reworked and simplified (maybe I will try to suggest something later). When you've never worked with a project management program and you directly start with ToDoList (as was my case), you have no reference point on how things need to be set up, and you're totally on your own with all these options. I think the program should impose a firmer vision of what is a parent task by closing certain options, or at least present the options in a different way in order to better guide the user towards the usual and recommended way of working.

[Ryan]

Djo…

I think we share a similar awakening about this topic and your comments on it are very useful to me. They help clarify my understanding of the hierarchical structure in TDL which is exactly what I was looking for.

I came from a perspective of using an outliner for my task management. Like you I had no formal experience with project management software or task managers per se. I have used both in the past but not deeply.

Instead I used an extremely powerful outliner for 27 years trying to shoehorn it into being a task manager. In later years thanks to some additional capabilities that were added I was able to write scripts to do complex things to the behavior of the outliner. At that point I was in fact able to make it a very useful and powerful task manager.

But I always felt that I was shoehorning something that wasn't designed to be a task manager into a task manager. And I think what we are discussing now is one of the quintessential differences.

An outliner has a different concept to its hierarchical structure than a task manager. It's much more generalized. It only requires that the "sub items" (an "item" was the nomenclature we used in the outlining world rather than a "task") have some sort of perceived relationship to the parent item. It is not necessarily a dependent relationship or a summary relationship. It is simply some perceived relationship of any kind.

When I saw a TDL I was blown away. It's the only program I have ever seen that rivals the outliner that I came from in its powerful brilliance. And....importantly... It was focused on tasks not generalized outlines. And it hit the other critical must have that I needed which was that it was NOT in the cloud... Something that is practically impossible to find anymore but still has a critical place in information management.

It wasn't until a few years ago that I began to realize that I needed a task manager not an outliner. An outliner was too generalized, and I was focused on tasks and a certain kind of relationship between them. I felt that as much as I had modified that outliner, and taken it as far as it could go to transform it to a task manager, it still was missing the mark for this purpose. Still the best program I've ever seen for outlining, but try as I may I could not make it achieve the level of task management that I dreamed of.

So sadly, after 27 years of using that amazing program, I searched for something else. That's when I discovered TDL!

And after a couple of years of using TDL now, I just very recently had the epiphany about the relationship between parents and children in the TDL hierarchy. I knew there was something that I needed to understand about task hierarchy, but I didn't quite grasp what it was. I was confused and that's why I raised this topic. I finally realized that the difference was that there was an implied dependency of the parent on the subtasks. This was an awakening for me.

Thank you for this discussion. I'm finding it very useful to both confirm my understanding and deepen it.

To add another dimension, let me give a COUNTER case... a case for passing attributes from parent tasks to subtasks in TDL that I use and find extremely useful. Granted this may be an anomaly in the behavior of the program that I have capitalized on and be an oddball exception to the desirability of strict bottom up transfer of attributes (from children to parents) that you are talking about.

I have a large project that I have to complete periodically. It has many levels of tasks and subtasks. The RELATIVE Start and Due dates of each subtask remain the same for each recurrence.

Instead of making all of the subtasks recurring so that they repeat on certain dates, I make them non-recurring ("Once") just setting their Start and Due dates for the current recurrence when I initially create them.

The only task that I make recurring is the root parent for the project. I set it to recur on the specific date that the overall project is next due.

Then, when the project is completed for the current recurrence, I set the root parent task to Completed and VOILA! ... all of the subtasks’ Start and Due Dates automatically advanced to the next recurrence and keep their relative dates (even though they are non-recurring tasks)! This works. It moves the entire project up to the next recurring time frame.

I love this! Not only does it make it easier to set up because I don't have to worry about recurrence of every subtask and I can add tasks easily simply by putting them in with their relative dates to the rest of the hierarchy for the current recurrence cycle, but it retains their Start and Due dates even after I set them to Completed without advancing them to the next dates. I find that useful as I sometimes want to refer back to the original dates on some completed tasks to help me keep the context of the hierarchy. And it can be confusing if they have dates for the wrong cycle on them.

I also don't have to worry about marking every single subtask completed in order to advance its recurring date. In some recurring cycles I may not have to complete all of the subtasks. Completed or not, it will advance automatically when I mark the parent task completed.

I use this kind of structure for any hierarchies that I have that have to repeat on a recurring basis. It's a kind of a template that can be reused simply by a single click on the root task completion that automatically sets all of the dates correctly.

I won't go much deeper into this as the point was simply to show that there are cases when I do want attributes to flow from the parent to the children including such critical attributes as Start and Due dates. Albeit I understand that this might only be because of the specific way TDL handles this action. But I thought it might be useful to mention this now.

[Djo]

let me give a COUNTER case... a case for passing attributes from parent tasks to subtasks in TDL that I use and find extremely useful. Granted this may be an anomaly in the behavior of the program that I have capitalized on and be an oddball exception to the desirability of strict bottom up transfer of attributes (from children to parents) that you are talking about.

The behaviour you've described (dates of the subtasks are relatively offset at each recurrence of the parent task), you can be sure that it is not an anomaly of the program but it is by design


I'm now going to go into more detail about my ideas of what inheritance should (not) be. Please, tell if you're not agree with me! (and if you are, you can tell too.. )

I think inheritance from parent to subtask(s) may be useful / legit in two situations: at the subtask creation, and when a task is copied / moved from another parent. For the rest, yes, for the moment I see no subtask attribute that should stay in sync with the parent...

I think now that the option 'Continue to update subtasks as parent changes' (in Preferences > Tasks > Default > Inheritable Attributes) poses a major problem in the way parent tasks are approached. This encourages a very confusing workflow, where we have both attributes of the parent that can be inherited by the subtasks, and attributes of the subtasks than can be calculated at the parent.

A more precise workflow should be promoted IMO by the program, for the sake of the user: modify almost only the subtasks and leave untouched the parent whenever possible, which would be considered as a summary of the subtasks.

Of course, attribute values could still be directly changed on the parent task, but without any automatic inheritance to the existing subtasks, to not bring confusion.

I've looked at some task / project management programs recently (not many), it seems they all consider a parent task as a summary task. In Microsoft Project, the parent tasks are even named 'Summary tasks' (https://youtu.be/EMNh9-00YXs)


Let's dig deeper with the inheritance 'parent to subtasks'. Again, I'm referring here only to the inheritance with the option 'Continue to update subtasks as parent changes' activated, which changes the attribute value of all the subtasks when the same attribute at the parent level changes.

When I look at the list of attributes that can be activated for inheritance from the parent, I don't want to tick any of them because I want to be able to manage the attributes of each subtask precisely. I don't think any of them deserve to be controlled by the parent task, which would be a bad workflow. Again, it's up to the parent task to summarize the attributes of its subtasks, not the parent task to impose the attribute values to the subtasks!

20230609-ven.16h17-02.png (11.11 KiB) Viewed 2891 times

I understand the inheritance 'parent to subtasks' is there for practicality reasons, so why it has been asked by some users. To change directly the value of an attribute at the parent level and it is automatically changed on the subtasks too, so you don't have to select the subtasks manually and then change the attribute for the selection (which is not a great effort by the way...), the program does these steps for you. So it saves a bit of time when you want to apply an attribute change to a branch of tasks.

But the price to pay for this is again IMO a lot of confusion. Changing an attribute at the parent level to apply it to all subtasks should not be, IMO, encouraged by the program with an automated inheritance feature. Instead, the program should IMO invite the user to consider parent tasks as summary tasks.

Changing an attribute value in an entire branch from the parent is, I think, something the user wants mainly during phases of reorganization of his tasklists (reorganize branches, changing category names, etc.), that is, during 'maintenance' periods on his tasklists. But it is not something that is really wanted in a daily workflow (outside 'maintenance' purpose). So IMO it makes sense to let the user makes those changes only manually.

The automatic inheritance 'parent to subtasks', in addition of being very confusing for the workflow, is "dangerous", because it's so easy to overwrite the attribute values of an entire branch, those you'd carefully set on each subtask.

Even without the option 'Continue to update subtasks as parent changes', it would remain easy and fast enough for the user to apply an attribute change to an entire branch (parent + subtasks), by selecting manually the desired branch and do the change manually (and it will be even faster with a command to select a parent with all its subtasks, which seems will be available soon). In addition to leave the door of a confusing workflow closed, not offer automatic inheritance would invite the user to target only the subtasks he wants for the change, and not automatically all the subtasks, for better control, precision and safe, because done manually, by voluntary action on his part.

So the option 'Continue to update subtasks as parent changes' is IMO not desirable to be offered. It would be highly desirable to add instead a lot of options on the summary (calculation) of most of the attributes from subtasks to the parent!

[Djo]

Let's continue a bit...

@Ryan , you've given a 'counter case' where inheritance parent to subtasks is useful and should be maintained. Your example was about the 'Completed' status. This is interesting...

First, let's think of any status but the 'completed' status: 'To Do', 'In progress', 'Waiting'...
It seems (to me...) that for these other statuses it makes no really sense to have an inheritance 'parent to subtasks'. Eg. if I set the parent to 'In Progress', should all the subtasks change then to 'In Progress' at the same time? No. This should work the opposite way: if one of the subtasks is set to 'In Progress' THEN the parent is changed to 'In Progress' too.

But there is something special about the 'Completed' status... Thinking about it, it is probably the ONLY attribute value for which the inheritance parent > subtasks is really relevant to activate (IMO).

And the program made no mistake about it. When the parent is completed, the status is propagated to the subtasks. It is a so obvious behaviour that even when the inheritance of attributes is completely disable in the Preferences, this particular inheritance is still enforced in some ways (proof: the pop-up to set the completion of the subtasks is always displayed).

So here the program considers that it doesn't make sense to maintain the subtasks in an active state as soon as the parent task is completed. The tree branch is completed (or 'cancelled'. We could say 'closed') when the parent task is completed. This enforced inheritance bypasses all the options in the Preferences. Fortunately the program doesn't offer an option to go against that!

So what tells this behaviour about parent task? That it is clear the program considers that the subtasks are included in the parent task. If the parent task is closed, the subtasks are closed. So it means the parent is a container for all its subtasks!

That may sound like an obvious epiphany. But because of the possibilities left open by the program, we almost doubt it...

I think it legitimates in a sense the idea that the parent task is (should be) a summary of its subtasks. On a container is written its content, right?

The size and aspect of a container is dependent of its content, right? It can't be smaller than the objects it contains.

But in ToDoList, the parent task start and due dates are, by default, not dependent of the subtasks (in Preferences > Tasks > Default > Attribute Calculations) :

So you can set a start date for a subtask in 2022 and a start date for the parent in 2024 for example, no problem. This is confusing again...

And the options
- 'Display a task's Due Date as the earliest of its due date and all its substask's due dates'
- 'Display a task's Start Date as the latest of its start date and all its substask's start dates'

are confusing too. Again here, we offer the user to not consider the parent task as the sum of its content (subtasks), so to not threat the parent as a container but as an independent task from its subtasks. For what benefit exactly? Mmmmh, I don't see. But confusion for sure.

IMO the proper behaviour is only the one in red (of course still with the possibility to change manually the dates on the parent afterwards if the user wants to):

IMO these options should be removed. I think they add nothing but confusion.



And you all, what do you think?
-----------------------------------------
- Do you use attribute inheritance (parent to subtasks), and how? Do you find it confusing? How does it improve your workflow, or not?

- How have you configured the options below? Do you find some of them confusing? Do you think they serve your workflow properly?

[Ryan]

This is a great discussion and I am looking forward to getting back to it. But I have not had any time recently... eventually I hope to take it up again. I find it very useful and thought provoking. I certainly wouldn't want any changes like that though without a lot more thought.

[Djo]

Thanks. What would be interesting is not to discuss too theoretically, but if people could share their own personal experience with the workflow on the mentioned subjects (eg. questions in blue above).

I have shared my own opinion and difficulties to set a proper workflow with the available options. It would be interesting to hear personal experience from other people.

[ispyridis]

@Djo
Attribute inheritance downwards example.

Using custom attributes I made a set of attributes that define the location if my tasks. As you describe above I use the parent tasks as folders.
The great thing about the settings you do not like is that I can take a branch of predefined construction tasks and copy them to a new location and all inheritable attributes get updated immediately.

What you think about Ms Project should tdl have similar capabilities? Or you think is out of scope. Because when I saw tdl I saw a serious competitor.

I like the flexibility of tdl being able to control parent folder as task is a plus for me. I can chose not to. But this flexibility is good because you might assign some paper work to close the task or made some preliminary work and started the task earlier than the subtasks. This work described in the parent tasks also has some cost so even the addition of the price of the parent tasks with the values of the subtasks works fine But also sometimes you need the synchronization which makes the program less error prone. I mean flexibility is good for experts. But novices might need to limit their choices and their workflow.

I see problems when we let subtasks out of parent tasks limits.

Also I want to note some things about parent tasks and subtasks.
A parent task can be a category of tasks.
For example electrical works and building works
These categories imply different supervisor electrical engineer, civil engineer or architect. The wall construction cannot finish if electrical lines have not been routed. So here comes the dependency to tasks that are not under the same parent. The parent is a grouping task that finishes after all subtasks are finished. Even as a category still works like that. The dependencies facilitate prioritization between all tasks.

By the way Ms Project at least old versions could not manage documents or links. Primavera project planner had a different package for contract management. Here I can assign all my agreements to the tasks or task sets.

This program can become the "Blender" of project management. Is very close to this level.