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
Make it configurable then … Let the user define ‘states’ in the Settings that can be specific to their workflow. The order of the ‘states’ is how you would switch between them when clicked.
For me the following would work best : TODO / DOING / WAITING INTERN / WAITING CLIENT / ON HOLD / DONE
But other flows would work for other people.
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.
ref chat: Discord
I second this. More workflow states, or configurable states would be awesome. Right now, properly handling next, waiting, delegated, etc. is difficult.
I agree that making workflows configurable seems like a better choice than extending the existing workflow with a new option: NEXT.
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.
Perhaps this plugin could help in some way?
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.