Task management devs - define a shared date and action format

[Kabo]

Dear task management devs,

thank you for all the work you’ve put in to create such diverse task management solutions that cater to a lot of different needs and preferences- we are lucky to have so many options! I’m sure many like one solution for some tasks and another for different tasks, or using a different plugin that augments features found in their ‘main use’ plugin. Or perhaps some like to switch between plugins for different projects, time of the year, etc.

The problem is that currently there are a variety of different date configurations options, from pop-up modals, to date pickers, to emojis etc, to let the plugin parse the date, rather than making use of the great natural language dates plugin and the DNP format.

Kanban plugin: - [ ] task 1 @[[2021-11-01]]
Tasks plugin: -[ ] task 1 2021-11-1
Reminders: - [ ] task 1 ([[2021-11-01]] 8:35)
Cardboard: - [ ] task 1 @due (2021-11-01)

I would like to propose a ‘date standard’ for all plugins, for greatest compatibility with each other, but more importantly for frictionless task entry and increased compatibility with core features of Obsidian (e.g. DNP and backlinks) and with Dataview.

The syntax would be text-based signifiers or key::value pairs and look like this:

• [ ] wash the car due:: [[2021-11-02]]
• [ ] submit abstract start:: [[2021-11-08]] due:: [[2021-11-12]] reminder:: [[2021-11-11]]

The advantage would be that it would help task data entered for one plugin work with others, e.g. tasks would render and be queryyable in all task management plugins - which would be amazing! Some examples: I could add a task that is queryable by the Tasks plugin in on my DNP template, as well as have it automatically appear in my Cardboard for a quick visual overview of this week. Or I could have a dedicated task master list via a Dataview query, but also have the task appear in my DNP backlink section or on my Kanban board - the possibilites would be endless!

However, to enable this glorious interoperability, all task management plugins would need to have a setting to switch on ‘use date standard syntax’ and all prior dates would get updated. In order not to break what’s working, this should definitely be an optional setting, so that users who are happy with their set-up do not have to change anything.

I am not a programmer (I don’t even know how to get the calendar emoji into my task on the computer without a lot of copying & pasting…), so I apologize if this suggestion is not doable or very difficult to implement, though I am hopeful, as I can see that the Reminders plugin offers a choice of date formats to use.

@schemar @rupert @uphy @mgmeyers

[mgmeyers]

I fully support a standard format and would be happy to update the kanban plugin accordingly!

An addition to the format that you propose that the kanban plugin needs is a way to define time in addition to date, which gets especially difficult if one needs to define multiple date/times. I guess one option would be to supply the full date-time as an alias: [[2021-11-02|2021-11-02 12:30pm]].

Also, I don’t use dataview, so I’m curious how the inline metadata would/could be used. Any examples?

Lastly, I know some folks don’t use daily notes. Forcing wikilinks as the date format is probably fine in this case, but it’s worth thinking about the utility of having a non-link format.

[mgmeyers]

Also, if we did decide on a standard format, we could create a standard library to handle the format (like obsidian-daily-notes-interface - npm)

[WhiteNoise]

I agree it would be useful to have a standard and I agree this standard shouldn’t be forced on users who do not use daily notes.

[mzantsi]

This promises not just a standardisation of tasks in Obsidian, but a new level of community engagement to connect the amazing and diverse development that is now occurring.

I would add “Scheduled” to the fields given the latest update to Tasks.

[friednslip]

this would be incredibly useful — +1 from me. Couple of things worth considering:

1. Supporting a standard keyboard trigger for all date entry— for example, the trigger for NLdate clashes with the trigger for Reminder plugin— I think the smoothest version of this is in @mgmeyers Kanban plugin, which works with NLDate but also extends it
2. Dataview syntax support would be hugely useful — especially if this also means that task management plugins are able to query the implicit and explicit fields that dataview adds to each task. This could potentially make each plugin a lot more extendible/ make it easier to support a huge range of task annotation depending on the inline dataview fields used Data Annotation - Dataview
   
   

[ryanjamurphy]

It would be good if a standard emerged. However, I think there’s value in diversity, too. If multiple options exist, there’s something for everyone.

Personally, I’ve been planning a task management plugin that will use daily notes to imply date metadata. The more implicit, the better!

[Kabo]

fabulous!

Admittedly, I hadn’t thought of times, so that does present a problem, but could perhaps be solved like in the Reminders plugin?

• [ ] do thing ([[2021-11-01]] 8:35)

To be honest, the main goal is to get a standard date and time format, so that it is cross compatible with all task plugins. Ideally one that is text based, or has emojis as optional ( I find them cumbersome to input and visually quite distracting, but maybe that’s just me )

Dataview may not be necessary, I have seen others recommend cross-compatibility, and hence included it, even so I am not a Dataview user myself - perhaps more knowledgable folks can chime in?

I agree that the daily note link should be optional, hopefully that would be an easy to implement setting (see the Reminders Plugin for inspiration)

[Kabo]

agreed - absolutely don’t want to stifle diversity! Ideally it would be a setting such as:

“do you want to use the Standard Date Format?”

If not toggled, everything stays the same!

Also, tell me more about your solution?

[rupert]

For CardBoard, I definitely do want to be supporting other formats - I picked one for starters that I kinda liked (it uses Taskpaper syntax). Like @mgmeyers - the ability to define time is also important in CardBoard.

I personally am not a fan of making the dates “linkable” as it kinda means you need to use the same format to name your daily notes - although perhaps this isn’t such a bad idea after-all (not really thought about it! - but I don’t have this in my vault at the moment).

Support for alternative standards would definitely be via some sort of configuration in CardBoard.

Interesting discussion!

[rupert]

CardBoard currently does this - if a task appears in a daily note, then this is used as the due date. You can over-ride this using an inline @due(YYYY-MM-DD).

[argentum]

Just going to drop this here GitHub - obsidian-community/obsidian-community-lib: An npm package of commonly used Obsidian plugin utilities.

[imed]

The only plugin that i know that uses natural language plugin is quickadd.

And given that you can specify the capture format into whatever you want, you just need to make a quickadd command for it and like you suggested you’ll be using nldates for all the different formats from all the plugins.

[veradrawer]

I love how much traction this is getting.

I’ve been weeks trying to make Kanban use compatible Task plugin cards, my current solution is muscle memory .

If we could make it link dates to daily notes, that would be it.

[Kabo]

I think this is a reasonably elegant solution - taskpaper format is established and could be adapted to suit. And @due @scheduled @start etc would be clear, or could be shortened to @d @scd @st (and could optionally be user-defined emojis).

Together with ([[2021-11-01]] HH:mm) this seems reasonable to me as it would work with both the Reminders date picker as well as the NL Dates plugin (with a different signifier such as ‘~’ or even ‘(~’ (instead of ‘@‘) to bring up date recognition.

What do you think?

[midas0441]

I like the idea of having standards, with some caveats to ensure that users have flexibility:

1. A common set of default keywords, such as due, start, done, would be nice to agree upon. To make it more flexible, it would be useful if plugins could allow a user to substitute something else for a keyword. For example, one might want defer or scheduled or an emoji instead of start. This could be a setting?

2. There are so many options and users work in so many different ways. It seems to me that agreeing to allow the user to choose the format would work best. Then user can pick among [[yyyy-mm-xx hh:mm]] vs [keyword::yyyy-mm-xx hh:mm] vs @keyword(yyyy-mm-xx hh:mm) vs so many other options.

3. This is probably beyond the scope of this discussion, and likely requires that the user adopt something with wider scope, e.g., Dataview, than a task-manager. Users may want to extend beyond the core common keywords. For example, wait, mile (milestone), annv, bday, etc. It would be great if users could add keywords that are tailored to their situation.

[Shruggie]

Just leaving this here: ISO 8601 - Wikipedia

[WhiteNoise]

While I appreciate the call for flexibility. I think hyper-customization gets in the way standardization and portability. Letting the users decide how to call the fields implies a centralized library (likely in core) to handle the user preferences, parse the files, and provide functions for all the plugins. Even if this is eventually done, the file produced are gonna be hard to parse outside Obsidian because every user can define their own syntax.

I instead propose to focus on agreeing on the bare minimum to get a task system going.

• IMHO, the absolute bare minimum is a do date. When you intend to do the task.
• The next thing to have is a due date. When is the task deadline.
• Extra reminders dates are nice too, but are not only tied to a task system. You may want to be reminded of note.

This can be done with a keyword before the date.
Something like

• !do or @do or do::.
• !due or @due or due::.
• !remind or @remind or remind::.

I am a little reluctant on choosing @ because @ is used in pandoc for citations.

The next problem is how to define the date (bare minimum) and the time for tasks.
I see two options.

1. A fixed date and time format
2. Have shared facility to get the date and time format chosen by the user.

Whatever the case is, it makes sense for the daily notes to use this format.

I am going to move this under #meta. Any input is appreciated, let’s try to be constructive and get this done.

[ryanjamurphy]

I guess it will be up to plug in developers to opt-in to such a standard.

I am personally discouraged by the direction of this convo, though. We’re talking about two things that are near and dear to my heart:

1. The use of syntaxes. In my experience, memorizing and writing syntaxes is poison. The more syntax, the more toxic. There’s an old CS maxim for this:

Programs must be written for people to read, and only incidentally for machines to execute.

And the author was talking about code! What’s it say about us if our task lists aren’t even people-readable…?

2. The ontology of task management. What is a task? If I’ve deferred a task, does it start on the defer date or afterwards? Does a task differ from a reminder? If a task is a reminder to complete a project, is it a project, a task, or a reminder? What does it mean if it’s all three?

If we’re really to go down this road, we need to bust out the UML and spend days/months crafting an ontology for task and project management. And I have some very strong opinions about the definition of e.g. projects, tasks, actions, reminders, events, deadlines, defer dates, start dates, end dates, due dates, and do dates…

I realize I’m being deconstructive here, but I think it’s necessary. All of these things—syntaxes and ontologies—are intensely personal. Everyone has a slightly different mental model for them. Standards that are overly prescriptive tend to be wrecking balls for personal mental models.

To try and pivot from being a downer, I think simpler is better.

For instance, here’s a simple “standard:” (Task) plugins should just always use daily note-format strings for dates.

Meanwhile, I propose the development of an interface (or something) for date-based metadata. There should be some way for Obsidian to build a calendrical model of a vault. That means:

• if a date (in daily note format) shows up in a block, relate the block and the date; and
• if a block, heading, or note reference shows up on a daily note, relate the block and the date.

How exactly those relations are defined should be up to the plugins that use the interface.

This would be useful beyond task management. It has implications for project management, historical studies, relationship management, basic calendar tooling, etc.

(I realize that some of this probably makes little sense—trying to get ideas out while doing childcare )

---

Aside: In my own approach to a task management plugin (still vaporware at this point), I’m really hoping to make it intuitive and natural for users to manage date metadata. One way I’m planning to afford this is via daily note structure. E.g., if a task is referenced under a ## Due: heading on a daily note, it’s due that day. At the same time, if the project note’s YAML metadata includes a date in the due: field, all tasks in that project are due on that date. The user will use either approach (plus a UX to support it) to manage due date metadata. (Obviously, this will be a lot of work…)

[Kabo]

Really interesting post, especially in light of the one directly above it in terms of individual choices and making it as bare bones as possible.

Im not sure if you mean me with this quote:

@ryanjamurphy

And the author was talking about code! What’s it say about us if our task lists aren’t even people-readable…?

That is certainly not what I am aiming for! My dream would be able to write tasks (or things I wanted to or be reminded of) in the way that I think, with as little distraction as possible.

Do the thing start:: next Monday due:: next Friday remind me:: every day in-between

But that is kind of beside the point of this post - which is to enable interoperability between different task plugins by using the same date format and ‘date trigger’ for parsing, so that the user can write a task and it will show up at the right time or be queryable in all the plugins.