One of the things that brought me to Logseq in the first place was that it already had task management built in, I didn’t have to spend a lot of time fussing around to add things like due dates, or searching for tasks that hadn’t been completed yet. However, I soon ran up against a different limitation: Logseq has no concept of “projects” - tasks that include other tasks. It does have pages however, but how to make pages work like projects? My earlier workflow (see here) relied on “page-tags.” You can set a page-tag for “status” to the value of “NOW” or “DONE” thus mimicking tasks. However, it never worked right for me. You couldn’t easily add due dates, check items off as done, or combine projects fluidly with tasks. Part of my workflow is the idea of “next actions” which would be sub-tasks for the project that should automatically show up on the project page as well as in your list of tasks on the home page. This new simplified approach solves all of these problems in a very natural way that does not require a lot of thought on the part of the user.
Pages are still at the heart of this approach, but instead of relying on page-tags, one simply places a task linking to the same page right at the top of the page. If you look at the sample picture above you will see that the project page is called “test project page” and the first item under the “project meta” subheading is a task which looks like this:
DOING [#B] #project [[test project page]]
That’s the heart of the system. Now that project can be searched along with all other projects (thanks to the #project tag), and when you click on the link in the task it will take you to the project page.
But where it really comes alive is in the two queries that lie just below the task. The first query “Related Tasks” gathers up all tasks anywhere in your graph that link to this page. This is how I handle next actions. For instance, if I get a call from a collaborator on the project asking me to submit a grant application today, I can just add the following task to my Journal page:
NOW [#A] write grant proposal for [[test project page]]
DEADLINE: <2022-10-27>
This will show up right there. I could even make “write grant proposal” into its own sub-project if I wanted and link to it there!
How about the second query? I use TODO tasks for quick checklists - items that are tasks but which I don’t want to show up in my list of next actions on my homepage. For instance, if I am writing that grant proposal I might need to do a bunch of small tasks which will only concern me when I am working on the grant proposal itself, such as
TODO find last year’s grant proposal.
These tasks will all be right on the project page itself, and might be nested deeply in the page. So this query simply pulls all those tasks together so I don’t forget any of them. (In the demo photo above they all appear right below the query which makes the query seem a bit redundant, but in practice they would be spread out throughout my notes.)
This is pretty much it, except that I also have a page listing all my projects. On that page I have a bunch of queries listing projects by whether they are NOW, DOING, LATER, etc. so I can quickly look over my projects.
I’m pretty happy with this new approach as it is. I have a template which adds the required metadata and queries to each new project page, so I barely have to think about it. I will share my templates here, as well as an explanation of how they work. However, first I want to point out two areas that still need work.
There are several plugins that add a “completed:: DATE” property to a task when marked as done. I use that for the third query which lists all related tasks that have been marked DONE. This is similar to the related task query above and not meant for checklist items on the same page.