> There can be conflicting state, for example: what happens if the parent item is checked, but the children are still open? Or the other way around? If all children are checked, shouldn’t that “automatically” resolve the parent? What if the parent has a closer due date than the children? And so on. While decision could be made for any of these corner cases, it might still feel strange in practice.
To me, the convention to go with seems easy.
1) If the parent is explicitly checked, leave the children as they are, and ask the user through tooling if they want to check each unchecked subtask, delete it, or move it up a level.
2) If all of the children are checked, the parent stays unchecked, but tooling should ask the user if the parent is complete, or if another subtask should be added.
3) If the parent has a closer due date than the children, don't do anything unless you feel like warning the user i.e. hold the subtasks to their due dates, and hold the parent task to its due date.
The issue about descriptions I see as a non-issue: dictate that descriptions marry to the task above them. It would be nicer to be freer with mixing descriptions and tasks, but you'd have to introduce more tokens.
One thing in the thread that I don't find necessary is marking partial completion.
I don't have any experience with Sublime, but this seems like a very basic tree.
When reading the subtasks, all you have to hold is the stack of the checkbox states and due dates of higher task levels for tooling to answer any of the above questions. A tool could seek backwards in order to check a parent if the children were checked, the user was warned, and the user said they wanted the parent checked. But if instead you really only wanted to read a line at a time, you could add a dummy item called "[ ] Complete parent task" at the end of the subtask list in order to keep an unchecked parent with checked children consistent.
The problem for me is that a tree is what I have trouble organizing. If it's just a linear list of things, I'm not sure how useful it could be for me other than by setting alarms that I could set directly. There is never a time when one of my tasks isn't to break down another task into simpler steps; all but the simplest tasks I have really have "break this down" that as the default first subtask.
So one workflow datapoint for useful with subtasks, useless without subtasks.
To me, the convention to go with seems easy.
1) If the parent is explicitly checked, leave the children as they are, and ask the user through tooling if they want to check each unchecked subtask, delete it, or move it up a level.
2) If all of the children are checked, the parent stays unchecked, but tooling should ask the user if the parent is complete, or if another subtask should be added.
3) If the parent has a closer due date than the children, don't do anything unless you feel like warning the user i.e. hold the subtasks to their due dates, and hold the parent task to its due date.
The issue about descriptions I see as a non-issue: dictate that descriptions marry to the task above them. It would be nicer to be freer with mixing descriptions and tasks, but you'd have to introduce more tokens.
One thing in the thread that I don't find necessary is marking partial completion.
I don't have any experience with Sublime, but this seems like a very basic tree.
When reading the subtasks, all you have to hold is the stack of the checkbox states and due dates of higher task levels for tooling to answer any of the above questions. A tool could seek backwards in order to check a parent if the children were checked, the user was warned, and the user said they wanted the parent checked. But if instead you really only wanted to read a line at a time, you could add a dummy item called "[ ] Complete parent task" at the end of the subtask list in order to keep an unchecked parent with checked children consistent.
The problem for me is that a tree is what I have trouble organizing. If it's just a linear list of things, I'm not sure how useful it could be for me other than by setting alarms that I could set directly. There is never a time when one of my tasks isn't to break down another task into simpler steps; all but the simplest tasks I have really have "break this down" that as the default first subtask.
So one workflow datapoint for useful with subtasks, useless without subtasks.