We currently have NOW / LATER, which provides the current and future state of tasks.
We can improve this by adding NEXT, representing the next set of tasks to be worked on.
Therefore we have active tasks(NOW), queued tasks to be worked on (NEXT), and tasks that must be worked on in the future (LATER) that require prioritization.
Note: the NEXT state should not activate the logbook. Time logging should only start with NOW and end with either NEXT or LATER
Making it configurable would be nice, perhaps a bit more complicated to implement(more dev time).
I handle your scenario with the following:
the client tasks will be in the client page/project, therefore the related pending task will be:
WAITING client [[@Client Name]] to complete x by [[scheduled/deadline]]
The client name will only be related to pages/blocks and tasks of the customer. Therefore negating the need to add client in the task workflow or using a namespace [[client/@Client Name]]
For personal one,
WAITING [[@Brother Name]] to call the insurance
This allows to use just one task state WAITING. I aim for less moving parts in the workflow.
Here is the workflow I aiming to use. the Next part is the biggest missing part at the moment.
Currently, you have TODO/DOING and LATER/NOW, and you have to decide which. Why not be able to define multiple workflows where each key word is considered a marker (a term used in plugins). Then clicking these marker words simply cycles through them. This would itself be more conducive to a better version of the Kanban plugin. Such a plugin would be turned on for a page and it would understand what columns should exist based on the existence of tasks and their markers.
In order for this to work, we will need logseq to support mapping a custom task keyword to a task “type”. Otherwise, adding a random keyword along with well known task keywords will be rendered as a text and not a task.
I’m curious why do you need to map adhoc vs. strategic onto TODO vs. LATER? There are several other ways to separate adhoc vs. strategic by using priority, tags, etc.
It’s actually not clear to me why Logseq offers two different task flows:
1/ TODO - DOING
2/ LATER - NEXT
More generally I’m curious about how people use the two different task setups in their workflows. Most people seem to just choose one or the other, and I haven’t seen any good use cases for using both together.
Logseq offers two task workflow:
1/ TODO - DOING - DONE
2/ LATER - NEXT - DONE
You can set only one by default. It is a matter of preference; both work the same way.
By setting one, the other one is still usable.
The idea I shared above is that, for smaller task, I use 1) and for longer running project, I use 2), because they have different constraints.
One could use only of those task workflow, with a combination of block properties to set task or project constraints