What is the current state of implementation?
I’m wondering if us users can help in any regard.
We need to make a decision and then devs can start implementing it. Not sure how to drive this to the end „community style“ with no one having real power/responsibilities.
Does anyone disagree with what @WhiteNoise proposed?
With due, do, starts, done and a default date of [[YYYY-MM-DD]]? With time being optional.
I just realized the semantics are not aligned. In my example, do is equal to scheduled. And start is equal to blocked until.
3 Likes
Looks good to me!
Just to be extra-clear, it would be:
do:: [[{a date format}]] {a time format}
- [ ] task1 due:: [[2021-10-01]] 10:15
Is that correct?
If so, I am all for it!
What is the effect of scheduled and blocked until in a practical example?
Or is it more conceptual, but does not have an effect on, say, a query (e.g. cannot show blocked until until the actual day is reached)?
I don’t have much to add that hasn’t been said, but I’d lean towards flexibility for user to define over presets. If there was a core “tasks” plugin that allowed for these settings and other plugins could read that would make it…easier?
One point, you can support arbitrary date formats using moment:
moment(date, dateFormat)
moment("1984-11-05", "YYYY-MM-DD")
moment("Jan 10, 2021","MMM DD, YYYY")
The challenge I believe is that if the user can change their date format at any time, what happens to all the previous dates in the old format? Do we need to update them all?
If we could include these due,do,done dates as a core plugin and integrate into the metadataCache…
Anyways, I like standardizing dates in plugins. Good convo!
1 Like
Yes, in my opinion it would be like you said. For example:
- [ ] Mow the lawn due:: [[2021-12-31]] do:: [[2021-12-21]] start:: [[2021-12-01]]
The difference between „scheduled“ and „blocked until“: „scheduled“ means you plan to work on a task on a certain day. You may want to see the task also the days before, because you could do it earlier and get it done if you have the time. „Blocked until“ means you cannot work on the task before that date. That means you do not want to see the task in your list of tasks before that date.
3 Likes
Thanks for the explanation, makes perfect sense!
How about putting metadata under the task?
Putting a bunch of metadata on the same line as the task causes a lot of line noise.
- [ ] Watch Required Training Videos
- due:: [[2021-11-30]]
- do:: [[2021-11-19]]
2 Likes
Actually better idea, maybe use add a block ref to the task and then store metadata in yaml. Not only is metadata then structured content stored in the same file, it wont clutter the rendered output.
Hi all, apologies for being late to this discussion. I love the direction that this idea is taking but I have one flag - Obsidian forbids *"\/:|? in filenames. I might be in the minority here, but I use @schemar’s tasks daily to organise my meetings. A common use case is this:
- [ ] 11:00 [[1-1 Jonathan 📅 2021-11-21]]
I will then put all of my meeting notes inside that note, along with any tasks and reminders for the next meeting.
The date format provided by tasks is really helpful for me in this context, as it differentiates all of these 1-1s into atomic notes.
If we were to replace the current format with due, i.e.
- [ ] 11:00 [[1-1 Jonathan due:: 2021-11-21]]
it would definitely break my workflow, as Obsidian doesn’t permit : in filenames.
Enabling users to select their preferred key::value pair format from a prefabricated list, per @mgmeyers’ suggestion here, would solve this issue. So:
- [ ] 11:00 [[1-1 Jonathan due:: 2021-11-21]] (not allowed)
could become:
- [ ] 11:00 [[1-1 Jonathan +due 2021-11-21]]
1 Like
I have spent some time reviewing all the task management plugins to get a better grasp of the issues. All the plugins implement different workflows (sometimes major, sometimes minor differences) and I agree with @ryanjamurphy that we should preserve this and not force all plugins to do the same thing.
The common thread for tasks is a definition of a date and meaning associated to that date.
For the date, I saw that all of you pretty much used ISO 8601 so I would stick with it. And if the user wants interoperability with daily notes, they are gonna have to use ISO 8601 for daily notes as well. Amen.
Regarding the tags, let’s just pick a few that we all agree on the meaning.
We could have something like
due:: 2020-12-01
do:: 2020-12-01
and if the user wants to link to the daily note explicitly
due:: [[2020-12-01]]
do:: [[2020-12-01]]
4 Likes
@WhiteNoise in this case, plugin authors could adhere to dataview’s existing api for task metadata: Data Annotation - Dataview
Dataview currently supports due::, created::, and completion::.
This won’t work for my needs in the Kanban plugin, though. For example, supporting arbitrary daily note and time formats is a hard requirement. In general, everything outlined in this doc would need to be considered: Obsidian Plugin Task+Date Format · GitHub
1 Like
Yeah, so basically in my last post I was suggesting to give up this hard requirement (arbitrary daily notes format). And everybody sticks to ISO 8601 and if the user wants interoperability with daily notes, they should also stick with ISO 8601 as daily notes format.
I am trying to reduce the number of moving parts.
2 Likes
A bit of a different take on this proposal (as I’ve been mulling over the same problem of lack of interoperability of task plugins) that maybe makes it more complex before making it simpler:
What if in addition to inline (ie in .md files) tasks, one could also keep one or more CSVs of tasks? In that case, any number of fields could be defined, but really only those in use in that file would be added as columns.
Ideally then the native tasks are truly “checklist” items related to the given note, but anything that goes much more beyond that (start/end/due/planned/recurring/etc) becomes a task in the database (that you maybe reference / transclude / backlink) to a given note.
Thoughts?
I am a simple user of obsidian and not a plugin developer but I would like to see that the core method of working with tasks is to be improved on instead of developing a standard for so many plugins.
To say it frankly and with respect to plugin developers … I think most task related plugins are not needed when the core task system would be improved on.
Some point to improve on the core task options:
Loose the need for "- [ ]"
Why does it need to be in a list? Feels very unnaturally when I am writing a text and add a task somewhere in the middle (on a separate row).
I understand we need some kind of syntax to define a task but a list should not be needed.
Things you would like to track about a tasks are:
- the fact that it is a task
- the status of task (todo, doing, now, later, waiting, cancelled, wait on client, wait on co-worker, anything you want). This status should be dynamic.
- date related values (created, started, due, scheduled, cancelled, done, also many more possiblities). Also be dynamic.
- are there more things to be tracked about a task … ? Not in my use case, but please add…
I think the assumption can be made that a task is always only on 1 row (although it can be on multiple lines in the editor). That seems reasonable to me.
With that in mind you could use the following syntax to work with the points mentioned above.
- If you specify that a task always has/needs a status (see point 2. below) that status is then the task defining syntax.
- The different statuses could be realised by using the status prefixed with a “//” (other modifier keys can be used ofcourse).
For example //todo or //waiting. The entire row without the // ‘fields’ would be the description of the task. - Same goes for date-related values only you combine the type of date with the actual date. Like for example //due//2022-03-21 or //done//2022-03-20. This needs to be added in the same row as the // to be applied to that task.
An example task would be something like so:
//doing Create the yearly report for [[John Doe]] //due//2022-03-20 to include the new formatting rules [[Cindy James]] will send to me //wait-on-coworker.
This is a task I am working on (//doing), for which there is a due date (//due//2022-03-20) and I am also waiting on a co-worker to give me some needed information to finish this task (//wait-on-coworker).
When the // fields could be shown in a different formatting by CSS that would be great also.
It is most easy to agree about a common date format but the the one used in daily notes settings could also be used. I do not know enough about the issue’s with different date formats.
together with changes to the default ```query possibilities so it recognises the “//” field for the use for tasks I think you then have a working task management that would eliminate the need for separate plugins.
You could make it all fancy from there on by adding the possibility to add a GUI that reads the lines with tasks (// fields) and create a GUI based on the fields used (like the tasks plugin does). And you could even make some settings to define the modifier key (in my example the “//” or define the different states and date values you want to use in the GUI.
I hope my explanation is clear. I am not a fan of plugins in general and I think a solid task management system should be included in Obsidian without depending on plugins. The current is IMHO not mature enough. Plugin can be created on top of a good task system.
But I like to know … what more would you need then statuses and date values … ? I know there is always more … but really?
This post has become a bit longer than I expected so I you made it to here. Thanks for reading … 
Regards, Jeroen
I also think as task to be a core functionality and for me tasks are typically related to any block in any note. Once again markdown is the limiting factor because it’s an unstructured graphical text representation with pretty loose syntax, and until people are afraid to make exotic extension to it (or accept that companion structured data is needed) they won’t be anything more than paragraphs with a square next to it. Even HTML allows more expressivity, semantic and extensivity.
I’m with you on the distinction between what should be core and plugin. For me plugins should be exclusively enriching concepts that the core introduces and standardise. When plugins starts to offer core and fundamental features it means the core is mostly empty, doesn’t drive the developpement. Having to spend time on different computers installing the same plugins and configuring them the same way is a bit annoying.
To push the concept further, core functionalities have the advantage of working in search, in editor, in auto-complete, everywhere, and then plugins can make the experience even richer by building on the strong foundation. When a functionality is brought by a plugin, it will only exist, work, sync and be extended inside that plugin. There is no commitment that the plugin will continue to exist or that the core won’t break it in the future, no guarantee other views will work with it.
I know developpers are just two and things won’t happen until long term, but i don’t see any blog talking about the future, about long term design directions, about roadmap or architecture. If i knew stuff is coming then i will stay for it and support it, but if all changes are little improvement here and there for the mobile experience, but things related to organisation workflow, knowledge management or big changes are to never happen or always as a “you can make it as plugin”, it will be hard to keep investing in the product which has a super promising start but needs to follow the curve and not stop in the middle.
So I hope they see obsidian as mid developpement and have a rich feature set for version 2 and not as a finished product that just need polish 
What is a “rich feature set,” to you? Be sure to post specific requests, or upvote existing ones that match.
This shouldn’t be necessary. It is easy to sync plugins and their configuration.
1 Like
Hi all,
As I was trying to make the Tasks plugin work with the Kanban plugin, I stumbled upon this post. I’m glad this discussion was initiated!
Has any progress been made regarding standardizing date formats for tasks?
While I still plan for Tasks to support the signifiers mentioned here, it will still be a while until it actually does. Time is scarce.
2 Likes
Unfortunately I’m not a developer and the topic of tasks in obsidian is a bit tedious for me.
I think there is a proposal for a standard format of tasks in text that is very widespread and it would be great if it were replicated in obsidian: todo.txt