After reading this discussion (with interest) I find myself able to see pros and cons for the various approaches/mental models being articulated.
Putting aside any tool being used, I do think that it actually seems reasonable to assume that if a task needs to be at different stages for different people, then it must implicitly consist of separate subtasks (be they parallel or sequential).
However, the separation of these subtasks as different ‘things’ (I’m avoiding using the word ‘entity’ to keep my thinking tool-agnostic) will lead to fragmentation, resulting in a loss of insight/coherence between them, as well as introducing extra work (mental and physical).
I don’t think there is a simple solution, but given how strong Fibery is/can be in terms of connectivity, it feels like it might be wise to choose to reap the value that comes from sub-dividing a task (separate workflows, and maybe more) so long as there is some clever, behind-the-scenes magic that maintains coherence, and minimises friction.
I haven’t yet worked out how best to do this, and different solutions are probably needed for different use cases, but off the top of my head, I could think of a few things to consider:
A ‘Split into subtasks’ button, that creates set of sub-tasks (one per assignee) or maybe a ‘Spawn subtask’ that creates a single, new subtask for the button presser.
Alternatively, a ‘Divide task’ that converts one task into many (resulting in peer tasks without parents).
Note: on a tangent, it might be worth thinking about whether there needs to be consideration of dependencies (i e. Does subtask A block subtask b?)
The key of course is to maintain some kind of relationship between the original and all the new (sub-)tasks. As long as relations exist, (sub-)tasks could have an automatic synchronisation mechanism, so that edits to relevant fields (e.g. rich text, status, comments, etc.) are reflected/aggregated where necessary in the parent/peer tasks.
Maybe the related tasks also need to have a rich-text field (+ others?) that is not to be synchronised?
Also, potentially there need to be buttons/automations to re-combine tasks if/when the division is no longer necessary.
Anyway, this is just mental spitballing, and some bits of this are harder to implement in Fibery right now than others, but I’m very happy to gather more feedback and even experiment with trying out ideas.
FWIW, the final implementation of ‘blocks’ will probably support ‘transclusion’ type behaviours, so I am quietly optimistic that the maintenance of coherence between objects will get easier and easier over time 