The next problem is how to define the date (bare minimum) and the time for tasks. I am a little reluctant on choosing because is used in pandoc for citations. This can be done with a keyword before the date.
Extra reminders dates are nice too, but are not only tied to a task system. IMHO, the absolute bare minimum is a do date. I instead propose to focus on agreeing on the bare minimum to get a task system going. 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. 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. I think hyper-customization gets in the way standardization and portability. While I appreciate the call for flexibility. It would be great if users could add keywords that are tailored to their situation. For example, wait, mile (milestone), annv, bday, etc. Users may want to extend beyond the core common keywords. 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. Then user can pick among ] vs vs hh:mm) vs so many other options. It seems to me that agreeing to allow the user to choose the format would work best. There are so many options and users work in so many different ways. For example, one might want defer or scheduled or an emoji instead of start. To make it more flexible, it would be useful if plugins could allow a user to substitute something else for a keyword. 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 like the idea of having standards, with some caveats to ensure that users have flexibility:Ī common set of default keywords, such as due, start, done, would be nice to agree upon. 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. 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. 
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! 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. The advantage would be that it would help task data entered for one plugin work with others, e.g. submit abstract start:: ] due:: ] reminder:: ].The syntax would be text-based signifiers or key::value pairs and look like this:
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. Kanban plugin: - task 1 plugin: - task 1 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. Or perhaps some like to switch between plugins for different projects, time of the year, etc. 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.
0 kommentar(er)
