NOW / NEXT / LATER tasks workflow

Feedback Feature Requests
1

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

2

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.

3 Likes
3

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.

image
image1673×1376 295 KB

ref chat: Discord

3 Likes
4

I second this. More workflow states, or configurable states would be awesome. Right now, properly handling next, waiting, delegated, etc. is difficult.

2 Likes
5

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.

3 Likes
6

Perhaps this plugin could help in some way?

7

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.

3 Likes
8

Are there any updated on this?

1 Like
9

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.

1 Like
10

I have been using [[@People name]]. What are you looking for?

11

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

1 Like
12

Instead of adding more build in workflows, it would make more sense to make tem simple configurable:

:workflows
 {:myflow
  [{:name "MAYBE"
    :class "yellow"
    :icon "fa-times"
    :next ["TOOK_NONE", "TOOK_1"]
   }
   {:name "TOOK_NONE"
    :class "red"
    :next "TOOK_1"
   }
   {:name "TOOK_1"
   }
  ]
 }

I think workflows should be configurable like:
:workflows {:myflow [{:name "MAYBE" :class "yellow" :icon "fa-times" :next ["TOOK_NONE"] } {:name "TOOK_NONE" :class "red" :next "TOOK_1" } {:name "TOOK_1" } ] }
Where you can define steps in the workflow. The keyword will be automatically styled correctly with the css class given and icon. If the next transition is a list with more then one entry, stepping forward will cause a tooltip with all possible steps. It would also be superb if backwards would also be possible. This simple state machine should allow everybody to easily implement any workflow.

1 Like
13

The plugin only helps a bit and feels alien. Ech workflow has a different shortcut. they don’t look like real workflow items. I tried to look into it and have maybe found a workaround with [:mark syntax. But anyways, this should be a core functionality