Plugin ignores tasks

[cja-github]

I think this is a great idea for a plug-in. The only thing is that it misidentifies notes as being tasks, and ignores tasks. Tasks are a standard feature in Obsidian.

The idea of a folder representing a project seems sensible and I do that myself.

A note in Obsidian is a list of lines of text. It is not a task.

A line of text can be a task.

A project management plugin for Obsidian should manage tasks within projects. Notes can be interesting context for a task, but they are not tasks.

I understand that it is useful to pretend that a note is a task because a note can specify fields in frontmatter. However using a note as a task works against the concept of tasks that is already built in to Obsidian.

I think it would be best to work first with the maintainers of the Advanced Task Plugin to add more fields to tasks and then to use tasks as tasks in this plug-in.

Continuing to pretend that notes are tasks will be problematic long term for several reasons, not least because it will make this plug-in unhelpful for those who use tasks are they are designed to be used by the developers of Obsidian.

In short, this is a promising plugin and I hope to use it once it is improved to work with Obsidian tasks.

P.S. I watched your video with Nicole vdH about the plugin. It does seem that you yourself use notes as tasks in Obsidian, which explains the design of the plugin. I'd be delighted to have a meeting with you to show how I use tasks in Obsidian to help you understand how powerful they are.

[marcusolsson]

Thank you for taking an interest in Projects and for taking the time to explain your concerns 🙏

While some views offer features similar to plugins that focus on task, I don't necessarily consider Projects a task management tool (I use the Checklist plugin for that).

Projects addresses the challenge of configuring data once, and then reusing it for different purposes.

I'm aware that the Markdown format supports tasks, and indeed several users have asked to be able to be able to edit them in Projects. Right now, I'm limiting myself to front matter and inline attributes until the type system is more mature, but I'd like to figure out how to extract more structured data from the rest of the note, such as tasks.

That being said, it might still not be what you're looking for. Project is note-based because I believe it's a useful abstraction. Each note, or record, can be uniquely identified through it's path and can contain a range of different well-defined attributes.

Had I instead chosen a line of text in a note as the core abstraction, I would need to define how to parse structured data from that line. For example, I could extract a task state, date, text, and a tag from the line below, but adding more data types would be trickier. Also, it's not obvious to me how to uniquely identify a task, maybe block references?,

- [?] 2022-01-01 Submit report #billing

I could add some structured data to the line in the form of a JSON object (which I know some plugin do):

- [?] Submit report { "due": "2022-01-01", "tags": ["#billing"] }

The problem that I see with the above is that users need to format their tasks according to a custom specification that Projects would have to define and document.

I'd like Projects to be easy to use, and to avoid users having to learn another format to be able to use it. I want to rely on already established formats and practices to lower the bar to learn how to use it.

I want to figure out how to extract more attributes from a note, such as tasks. For the Board view, that could mean that each card can have a checklist for things to complete before the card can be considered done.

Projects aims to provide a well-typed data structure to views based on plain Markdown without defining new configuration formats, and instead rely on existing best-practices. Tasks are coming when I figure out how to fit them into the type system. Right now, only simpler data types are supported.

[cja-github]

Hi Marcus, Thank you for your detailed reply. I was attracted to the plugin by its name, because I was already using Obsidian to manage projects and was hopeful that a plugin called Projects would be useful in helping manage my projects, which are made up of notes containing tasks. You mentioned in the video I watched that you think of the source data for your plugin as records instead of notes, and you have done so in your reply to me. Your plugin provides ways of viewing and editing folders of notes by their metadata. It provides the same viewing functionality for Dataview table query result sets. Therefore "Record" is sensible terminology. I think if you had called the plugin "Record Manager" then I would not have been confused :) You are choosing to prioritise record metadata functionality over task functionality, which makes sense for Record Manager. If you decide to continue with Projects (instead of Record Manager) then you might look into the Advanced Tasks and Dataview plugins because they seem to have solved the unique task identification problem. Your plugin seems well made and I look forward to seeing how it evolves.

…

-- Christopher Alexander ***@***.***

On Sat, 19 Nov 2022, 09:22 Marcus Olsson, ***@***.***> wrote: Thank you for taking an interest in Projects and for taking the time to explain your concerns 🙏 While some views offer features similar to plugins that focus on task, I don't necessarily consider Projects a task management tool (I use the Checklist plugin for that). Projects addresses the challenge of configuring data once, and then reusing it for different purposes. I'm aware that the Markdown format supports tasks, and indeed several users have asked to be able to be able to edit them in Projects. Right now, I'm limiting myself to front matter and inline attributes until the type system is more mature, but I'd like to figure out how to extract more structured data from the rest of the note, such as tasks. That being said, it might still not be what you're looking for. Project is note-based because I believe it's a useful abstraction. Each note, or *record*, can be uniquely identified through it's path and can contain a range of different well-defined attributes. Had I instead chosen a line of text in a note as the core abstraction, I would need to define how to parse structured data from that line. For example, I could extract a task state, date, text, and a tag from the line below, but adding more data types would be trickier. Also, it's not obvious to me how to uniquely identify a task, maybe block references?, - [?] 2022-01-01 Submit report #billing I could add some structured data to the line in the form of a JSON object (which I know some plugin do): - [?] Submit report { "due": "2022-01-01", "tags": ["#billing"] } The problem that I see with the above is that users need to format their tasks according to a custom specification that Projects would have to define and document. I'd like Projects to be easy to use, and to avoid users having to learn another format to be able to use it. I want to rely on already established formats and practices to lower the bar to learn how to use it. I want to figure out how to extract more attributes from a note, such as tasks. For the Board view, that could mean that each card can have a checklist for things to complete before the card can be considered done. Projects aims to provide a well-typed data structure to views based on plain Markdown without defining new configuration formats, and instead rely on existing best-practices. Tasks are coming when I figure out how to fit them into the type system. Right now, only simpler data types are supported. — Reply to this email directly, view it on GitHub <#164 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABIIJTZ635VOEGJ6ILGNJCDWJCE3ZANCNFSM6AAAAAASE6IU4Y> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[marcusolsson]

I'll admit that naming things isn't my strong suit 😅 Sorry for the confusion!