Taskidian [Unwonked]

Untangling my task and project management approach, at last.

Back in March, I wrote a post called Taskidian [Wonkish] in which I laid out the {excrutiating] details of a task and project management system I had been evolving, first in Typora and most recently in Obsidian.

Because of several advances — most specifically because of innovation in the Dataview plugin for Obsidian — I have been able to dramatically simplify my approach.

I will not recapitulate how the older version of Taskidian functioned in this post. You can look at the earlier post, although it’s not necessary. Instead, I will describe how I leverage the power of the new functionality in Dataview to gain a powerful but easy-to-use task management system.

Taskidian Tasks

Dataview now supports multi-state tasks. Instead of simply having two states, like these —

- [ ] an open task

- [x] a closed task

— which render like this in my Obsidian theme, Minimal —

— now, Minimal (and other themes) support a long list of alternative task states.

Here’s the subset I am now using.

potential tasks (not yet started)

- [?] possible

- [I] idea

- [i] information

active tasks

- [ ] to-do

- [!] urgent

- [/] blocked (waiting for something)

- [>] forwarded

inactive tasks

- [x] done

- [-] canceled

These render like this (courtesy of Minimal):

Tasks can have other Dataview attributes, such as due dates, and any arbitrary inline YAML values.

I use a convention for project names based on the option-o character (ø) like this:

- [!] [ø:: work futures] some text perhaps with a [[file reference]]

As we will see, the inclusion of Dataview values means that queries can be structured to search for and organize search results based on values like work futures and the specific status text indicated by the task status, like - [!].

The typical lifecycle of tasks is one of a few paths:

1. I create an active task — either to-do, urgent, or blocked — and after it is complete I check it off. This occasionally involves being blocked — such as waiting for someone to respond to a request, or a subtask to complete — and very infrequently, an active task is canceled.

2. I create a possible task, often with a link to a web page or an Obsidian file or block, and at some later date I might activate the task by getting rid of the question mark, but in general I often just perform the possible task and check it off.

3. I use the forwarded state in a very specific way. In my daily notes, I define tasks that I intend to do each day (in principle). Some are links to tasks defined in project files (about which more later), some are defined immediately in the daily note, and some are ‘carried forward’ from an earlier daily note. I ‘carry forward’ a task manually, cutting and pasting it from (for example) 2022-04-10 to 2022-04-11, changing the task status to forwarded.

Taskidian Queries

Here is a Taskidian query that shows all overdue tasks. It relies on the Dataview attribute [due:: <somedate>].

```dataview

TASK WHERE (status != "x") AND (status != "X") AND (status != "-") AND (due < date(today))

GROUP BY due

```

This yields this:

The results show a peculiarity of Dataview. Although the plugin has been retooled to deal with a variety of task status values: when the results of a search query are rendered all the tasks are shown as plain vanilla to-dos, without the various statuses displayed. A second peculiarity: I don’t want to show canceled tasks or closed tasks. It turns out that some of the mechanisms for checking off a task to close it do so by placing an uppercase X in the checkbox (most notably when checking off through a Dataview query or through transclusion). So I have to test for lowercase and uppercase x.

I rely on a variety of YAML inline attributes on tasks. For example, I use the convention of naming projects in this way, with option-o:

[ø:: work futures]

and subprojects with double option-o:

[øø:: antiwork]

In this way I can group or select tasks by projects and subprojects.

For each major project I create a top-level folder in my vault — like 00 work futures, and within that folder a file for status: work futures status. In that file I have a dataview code block like this:

## all incomplete tasks by subproject/theme

```dataview

TASK

FROM "2022 journal" OR "00 work futures" OR "2021 journal" OR "00 other projects" OR "00 the river" OR "00 reworked"

WHERE (ø = "work futures") AND (status != "x") AND (status != "X") AND (status != "-")

GROUP BY øø

```

The FROM clause restricts the search for tasks: in particular, I want to avoid pre-2022 folders, because there are a lot of incomplete tasks in 2020 and 2019 I don’t want to deal with, defined before I was using Obsidian.

The WHERE clause filters to open tasks connected to the work futures project, and the GROUP BY organizes results by subproject. The results are like this:

I have also created a number of queries organized around due dates, and these I keep close at hand in the right-hand margin. Here’s the query for overdue:

```dataview

TASK FROM "2022 journal" OR "2021 journal" OR "00 other projects" OR "00 work futures" OR "00 workings" OR "00 cisco" OR "00 the river" OR "00 reworked"

WHERE (status != "x") AND (status != "X") AND (due < date(today))

GROUP BY due

```

With results like these:

I have defined dataview queries for due this week, due this month after this week, due next month, due soon (for tasks with attribute [due:: soon]), due next, due someday, and a number of others. These work because of the fluidity of the due attribute, which is a text string, but can be cast as a date, too.

Kanban

I occasionally use the Kanban plugin for Obsidian, but not much with regard to organizing tasks that I have defined in my daily note or other working files. I do use it as a planning tool for projects, when thinking about staging phases or the like. However, I hope the developers will come up with support for ‘swimlanes’, which is essential for that kind of planning.

I might use Kanban more if it were somehow married up with Dataview. Imagine if a dataview attribute like due:: or øø:: were mapped to the columns in a Kanban board, and the list in each column would be tasks that have been defined anywhere across the Obsidian vault (filtered by FROM and WHERE), and not just cards defined manually in the Kanban, itself.

I do use the Kanban plugin to organize writing long-form pieces, which I have written about in Card-Based Writing in Obsidian Using Kanban.

Putting Taskidian In Context

My personal context has shaped Taskidian: this approach to task and project management is a direct reflection of the way I work and the sort of work I do.

Mostly, I am researching topics in the future-of-work domain, and when I find bits of information that can prove useful I copy them — either manually or with tools like Hypothes.is or Glasp — and then create tasks embedded in the written context. I journal my work every day, and create tasks in the journal entries, particularly daily notes but also in journal entries within project folders.

I find that I have arrived at a point in my task and project management that is much like what Andy Matuschak wrote about in Close Open Notes:

Tasks left undone, observations left unrecorded, replies yet to be written—these swirl about our minds, as if we’re rehearsing them over and over again to make sure they’re not forgotten. To get rid of this nagging and create a “mind like water” (to use the term in Allen, 2015), build systems to reliably close these open loops.

For instance: for operational to-dos, this means (Allen, 2015):

1. You should be able to record a task anywhere

2. You regularly drain tasks from this list

3. You regularly delegate, refactor, or delete tasks which you can’t prioritize

Taken together, these properties ensure that when you record a task, you can stop thinking about it. Ubiquitous capture isn’t enough, as most to-do systems demonstrate. If you don’t regularly review your task list and decide to delete or re-strategize lingering tasks, you won’t be able to trust that you’ll follow up on tasks you record.

I record tasks anywhere, and rely on Dataview queries to serve them up when I need. I regularly drain tasks, and I delegate, refactor, or delete tasks I can't prioritize.

I expect that the delegation of tasks in the Obsidian context will have to wait for a general model of sharing — including cooperative editing a la Google docs, and task assignment — and that will likely be the time when I will next revamp Taskidian. But for now, I am closing those open loops.