Better urgency mechanism

[tbabej]

I've been thinking recently about the urgency computation. I wonder if Taskwarrior users have ideas around how the urgency should be improved changed.

The current mechanism is a linear polynomial with customizable coefficients, which roughly assumes the following:

• the older the task is, the more urgent it is
• more overdue the task is, the more urgent it is
• the more tasks the task is blocking, the more urgent it is
• the more information has been captured with the task (tags, annotations, project...), the more urgent it is

The first three assumptions seem to be sound, the fourth seems like a bit of stretch. Just because I annotate a task with an URL, it does not have to mean the task is more urgent. What are your pet peeves with urgency calculation and what would you wish Taskwarrior could perform when sorting the task according to urgency?

[mrossinek]

In general I would like to say that I am quite happy with the urgency mechanism. Nothing obvious is not being taken into account and the tasks usually do agree with my personal taste of their urgency.
However, I have to agree that I find the fourth point in your above list difficult to support. I often annotate a task with a link to a note or website which relates to the task (often Github issues). This does not grant a higher priority to the task in 99% of my use cases.
Since many of my tasks are annotated, this effect essentially cancels out though..

[mrossinek]

It just came to my mind that the scheduled attribute could also be taken into account in this equation. Consider e.g. that I have some task which is due in the far future (say in 2 months from now) and I schedule to tackle it in e.g. 1 month from now.
This task should be lowered in priority until the scheduled date approaches and should be exceedingly higher in priority the farther the scheduled date has been surpassed.

This may be a little niche because arguably one could let this task wait until the scheduled date but in some cases I prefer to have such tasks visible in my common report rather than having to check the list of waiting tasks.

Come to think off, should wait affect the urgency? 🤔

(@tbabej tagging because I don't know how the notifications work on comment replies...)

[jaker-dotcom]

I mean tasks with wait status don't show up in many reports so why should it affect the urgency? I use urgency only to find out what is actionable right now.
When reviewing tasks for the future I'd even say that lowering priority of tasks further away is even worsening the only situation where I could imagine where priorities of waiting tasks matter: Finding out what important tasks are coming up within the next month e.g. when you leave for a month. You could list most important tasks of that month and don't this view to be distorted by how late in the month the tasks are.

I very like the idea you propose for scheduling though. It's just that I schedule little so I don't care much either. I am very happy with the urgency algo!

[aurbman]

scheduled tasks automatically get a +5 in urgency which doesn't necessarily make sense to me. I also think that the age calculation should be based on the scheduled attribute if the task has one, otherwise it uses entered.

[jaker-dotcom]

scheduled tasks automatically get a +5 in urgency which doesn't necessarily make sense to me.

Well if it is planned to do it right now it does make sense to me since it ensures that the task is on the list. Imagine a truncated tasklist and the scheduled task is being cut off.

[mrossinek]

I actually came across something which I had not noticed before: dependency chains are not very well reflected in the urgency. Right now, you can only check whether BLOCKED and/or BLOCKING are set. However, consider a scenario of three dependent tasks:

% task add "Task 1"
Created task 1.

% task add "Dependent task" depends:1
Created task 2.

% task next
ID Age   Deps Description    Urg
 1  1min      Task 1            8
 2 19s   1    Dependent task   -5
 
 % task add "Dependent of dependent" depends:2
 Created task 3.

% task next
ID Age  Deps Description                 Urg
 1 3min      Task 1                         8
 2 2min 1    Dependent task                 3
 3 2s   2    Dependent of dependent task   -5

As you can see, adding the third task did not affect the urgency of task 1. I know that implementing this would require traversing the entire dependency chain but arguably this could be an improvement to consider.

What do you think?

[tbabej]

There is urgency.inherit setting that should give you the behavior you expect:

       urgency.inherit=0
              Not actually a coefficient. When enabled, blocking tasks inherit the highest  urgency  value  found  in  the
              tasks  they  block. This is done recursively.  It is recommended to set urgency.blocking.coefficient and ur‐
              gency.blocked.coefficient to 0.0 in order for this setting to be the most useful.

[mrossinek]

Oh I didn't know about that! Nice! Works like a charm 👍

[rcaputo]

Task prioritization is very personal. I don't think just exposing single coefficients is enough.

For example, I'd like to try @mrossinek's idea that "scheduled" urgency could be negative prior to the scheduled time, but I don't think I can do that with how taskwarrior applies urgency.scheduled.coefficient.

I wouldn't mind seeing the urgency calculations offloaded to an embedded interpreter with user-serviceable scripting. If task's expression parser isn't up to the... isn't up to it, lua is nice.

Short of that, each time-gradient coefficient needs something like six parameters to be completely configurable. This illustrates a hypothetical scheduled urgency that scales from -10 to +12 over the fortnight before the scheduled date.

urgency.scheduled.start.coefficient = -10   # value to apply starting at start.moment
urgency.scheduled.start.moment = -14d       # relative from the field
urgency.scheduled.start.persistent = true   # does start.coefficient apply before start.moment?
urgency.scheduled.end.coefficient = 12      # value to apply at end.moment
urgency.scheduled.end.moment = 0d           # relative from the field
urgency.scheduled.end.persistent = true     # does end.coefficint continue to apply after end.moment?

[djmitche]

Could a hook accomplish this? I suppose a downside of hooks is their performance. Still, it might be more in line with hooks to use the UNIX philosophy here and actually rely on an external executable, rather than an interpreter. Perhaps urgency could be calculated with a program that runs once and takes a series of tasks on its stdin to and returns urgencies in the same order?

[rcaputo]

A hook can accomplish this but not as well. Serializing and parsing the full contents of every non-pending task matching a report filter might become unwieldy for people with a lot of tasks.

It has to be full contents of each task unless task knows in advance the subset of fields the hook needs. It has to be all the matching tasks if urgency plays a part in determining which will or won't be displayed.

An embedded interpreter can be pretty lightweight if it's designed for embedding. I've seen lua used effectively for scripting and configuration in a number of places: wireshark, wezterm, neovim, nmap, vlc, CHDK, etc. Binary builds appear to be around 300K-500K, including standard library.

task's native expression evaluator might be enough, especially if a ternary ... ? ... : ... operator were added.

I don't think the "do one thing well" philosophy applies as strongly when the things in question can't be used separately to do anything else. Then it's more like N things each doing 1/N things well.

[rcaputo]

I think "scheduled" might need a rethink in general. It's documented as "the earliest opportunity to work on a task".

All tasks have such a moment, which may vary over time.

That moment for an unscheduled blocked task is when it finally becomes unblocked.

For an unscheduled task that has never been blocked, that moment is when it was created.

[rcaputo]

It might be nice for urgency.blocked.coefficient to change so that tasks with longer blocking dependency chains have lower urgency. Currently urgency.blocked.coefficient seems to apply just once.

In the example below, one might expect "Blocked Child" to be slightly more urgent than "Blocked Grandchild". However, if all other urgency modifiers are equal, they will have the same urgency. Because of the equal urgencies, it's common for reports to show blocked grandchild tasks above the tasks they depend on.

This is admittedly minor. They're all blocked. But some are more blocked than others, and I am particular about the order of my lists.

graph TD;
    A["Unblocked Parent"]---B["Blocked Child"];
    B---C["Blocked Grandchild"];

Loading