Inherited Priorities

I’m on holiday hence the two idea posts back to back.

The Issue

I like the idea of priorities for evaluating what you should do next but when we introduce subtasks it seems to me there’s a weakness.

For me the whole point of subtasks is to organise the jobs we need to do in a more managable way right? So what do we do when we have subtasks and want to assign them priorities. Of course we can assign every block it’s own priority but this seems laborious. And it’s not flexible at all which with a program like Logseq that allows transclusion and infinite referencing seems not the idea.

Solutions

Theoretical Solution.

What I thought would be ideal is inherited prioties. The idea of this is that a subtask should be at least as important as its parent task without us having to manually state that. Otherwise why is it a subtask in the first place.

If you learn by example

Lets set numerical values to prioties to make it easy to calculate
A: 3
B: 2
C: 1

  • TODO [A] Prepare for trip next week.
    inherited priority:: 3
    • TODO Check where you stayed last year
      inherited priority:: 3
      deadline:: today
    • TODO [A] Check where the conference will be.
      deadline:: today
      inherited priority:: 3.3
  • TODO [B] Find that book
    deadline:: today
    • See if you can find that book you saw last week in the shops.

With the above if you sorted for tasks due today you’d normally get this

  • TODO [A] Check where the conference will be.
  • TODO [B] Find that book
  • TODO Check where you stayed last year

That’s fine but as preparing for your trip for next week is a top priotrity then Check where you stayed last year should in my mind be higher than trying to find that book you heard about.

Actual Solution 1: Query Based

There are two approaches to this I can think of but I’m open to suggestions.

I’m not fluent enough in datalog to write this but it seems possible. (skip ahead for an example to work with.)

When sorting by priority every block would have an inherited priority value (made up when the query was performed not inherent.)
This value would be made up of the parent node’s inherited priority plus the current node’s priority. Of course if the parent TODO has a priority of A then the subtask should start with 3 and then add it’s own priority but at an order of magnitude lower. Hence 3.3 for a priority A subtask whose parent is also priority A, or 3.2 for a priority B subtask whose parent is priority A. This should make the maths work out but correct me if I’m wrong.

Actual Solution: 2 Inherent System

Each node could calculate it’s own ‘inherited priority’ by basically doing the above dynamically.

I suggested this hoping it wouldn’t be too off the wall because most other stuff logseq does (like references and transclusion) is already dynamic so I didn’t think it was unreasonable.

I think I’m basically suggesting that the system has the above query method inbuilt. In fact giving us a way to reference this in advanced and simple queries would probably be the best way to do it I can think of.

Issues

Scaling and Performance

The biggest issue that jumps to mind is that of scalability with multiple levels of subtasks but I feel like practically there are only so many subtasks that we as humans can manage so I’m hoping that it won’t be an issue.

What if the tasks parent node isn’t a task but it’s grandparent is.

Honestly I would treat any task whose parent isn’t a task / doesn’t have a priority as simply having no inherited priority.

the reason there’s still the opening for a non-TODO item to affect it’s children’s inherited priority is that you might make an event that’s not a job but then assign that event a priority.

e.g.

  • [A] Meeting with Manager 09:30

Isn’t a task as such that needs to be ‘done’ but it’s logically high priority and thus and children should be automatically assigned the same priority without you having to specify it hence the below.

  • [A] Meeting with Manager 09:30
    • TODO Prepare
      inherited priority:: 3
  • TODO [B] Get more pencils

Conclusion

My hope is that this feature will make organising things easier without having to explicitly state qualities of jobs etc which really should be obvious from context.

I believe you can do this to some extent already with the amazing templates plugin. But as with everything something hard baked would normally be better.

I doubt that this will ever be implemented, because it covers a narrow family of cases (so it is not generic enough) and queries already cover such cases (granted that such queries are not easy).

No that’s fair I shall have to work on a nice query to convert the priority to a numerical value and then sort by that value.

Thanks again for your response it’s very much appreciated.