We would love to hear how people would use this and what they expect to happen with all the data associated (comments, lists, etc.)
I use some lists for tracking tasks connected to a development of certain feature or document, and these lists are grouped together in a set of folders (a folder for software development, a folder for law texts commenting etc.) - folders allow me to have a predefined set of custom statuses (inherited by all lists).
Sometimes, what seemed like a large feature with too many steps and therefore was made list, would become better as a single task with subtasks to be more manageable.
List info should be moved into task's description, attachments, owner>assignee. Statuses should be resolved by the same logic as in moving a task from a list to a list (ergo ask user to map the statuses), based on the destination list for the converted task.
Potential problem would be converting a list with tasks which already have subtasks - maybe asks user, if he/she wants these to be merged into other subtasks of the converted task, or maybe merge these into description of the subtask with check boxes or optionally convert them into a checklist?
At first blush, a single task may seem sufficient but then it explodes in scope and complexity, and needs to become its own project. Conversely, something that seemed big initially may have a slower velocity, and be "just" a single task with subtasks. Good for the user to have flexibility in toggling these.
Most common use I foresee will likely be making a task into a list. My experience has been that people are more likely to under-scope and underestimate and have to endure scope creep, than overestimate and have to scale things back.
This feature would be great especially if we can set/tag certain tasks as parent/child which would be very useful to easily define epics or OKRs.
PS: I do not like to use "Goals" for epics...
What I mean is that many times when planning many KR become Objectives and so need to breakdown tasks even further...
I think Noam mentions most of the reasons to use this feature. Of course, it does depend on your personal setup. I think most users - and please correct if I’m wrong - use the current structure in either these two ways:
- Folders to group projects
- List for projects
- Tasks for tasks
- Folders for projects
- Lists to group related tasks
And like Noam mentioned, it may occur (and to me it often does) a task becomes so big it turns out to be a project itself. If David Allen would use ClickUp (and he should!) he - and all of his GTD enthousiasts - wIll even define any tasks with more than one subtask as a project. So when using the above mentioned setup, you want to easily convert an expanded tasks into a project a.k.a. a list.
For the same reason, I think it would be a timesaver to convert a list into a folder. Tasks within that list will become lists and subtasks become tasks. It all moves up to a higher level within the structure tree.
Any differences like defined statuses can be detected, prompted through a pop-up and adjusted by the user. Just like now when moving a tasks into a different folder.
Elements that are missing between tasks and lists can either be removed or left empty. Or add to the pop-up so the user can add those elements right away.
A lot of operations come with a basic expectation of symmetry. If you can type a letter, you should be able to delete it. If you can move a card forward, you should be able to move it backward. There are a million such examples simply because it's so basic we don't really think about it. In the same way, if you can convert a task into a list, you should be able to convert a list into a task.
Here's a basic, and specific, reason. Maybe I made a mistake when I converted a task to a list (and it's too late to undo), so now I'm just putting things back in their place.
But there's also a better usage. When working on tasks, I'm always fiddling with the hierarchy. Some things don't change much, but others change often. Tasks are demoted to subtasks, and vice versa. They're moved from list to list. Lists are moved around as well, from folder to folder and even between spaces.
Sometimes a task starts small and then I start adding subtasks, and before long I realize that it's much bigger than I thought. Now I manually create a new list (named after the task), and manually move all the subtasks to the new list. A simple operation could do this much more conveniently.
A more general approach is perhaps to simply allow nesting at any level (as some other task managers do), and show the tree (including tasks that have subtasks) in the hierarchy. I realize this is much more complicated, but I bring it up here to offer another way to look at the relationship between lists and tasks. Maybe the distinction should be a bit more fluid.