[TW-74] Advanced urgency co-efficients
David Patrick on 2012-08-19T20:28:33Z says:
note: this one may be a bit far-fetched, as in v 2.3? :-)
Urgency coefficients are friggin' awesome, and generate a credible list sorted by what's most important, and the fine-grained configurability is really unparalleled in the sphere of TODO apps.. and STILL I'm not satisfied! .. ok actually quite satisfied, but I got a notion how the awesome could be awesomer, and so I share.
So almost any attribute of a task can be assigned an urgency-coefficient, and the sum of those coefficients determines the overall urgency score for that task, and can place it in the list accordingly. Works great, makes good lists, but this feature request looks to extend the coefficient value from it's current "any real number" to allow for reference to other attributes and simple equations.
let me start with the simplest example I can think of. Imagine a UDA "rating" which establishes how much fun a task would be, on a scale of 1 to 5. The way UDAs work now, I could affix a coefficient number to the UDA, that number applies if the record has that UDA.
bq. urgency.uda.rating.coefficient=5
but that doesn't allow the rating itself to have an effect on the overall urgency score. what if I could say
bq. urgency.uda.rating.coefficient=%rating
may seem a bit mysterious, because the coefficient is referencing the value of the attribute, and it helps that the attribute is of the type=numeric, but that suddenly allows the value of the attribute to have an effect on the urgency, not just the presence or absence of a value.
If I could also use simple equations, I could translate that rating:value to have a different effect on urgency with
bq. urgency.uda.rating.coefficient=((%rating - 3) * 6)
then a 1 - 5 rating:value becomes urgency coefficients -12, -6, 0, 6, 12.
Here's another example, let's say we had a "cost" UDA, and guess what? the more money, the more important, so we might define it as
bq. urgency.uda.cost.coefficient=(%cost * 0.02)
and the big-ticket item would float upwards.
That's fine for the numeric-type attributes, but I can also see where constrained string-type UDAs might have an urgency difference inferred by the position in the list of UDA.values. If, for example, you used a "state" UDA, with constrained values from "proposed" to "released", we might extract an urgency value by counting the position in the values list, supposing that the more advanced the state of a task, the higher the urgency to complete it. We could assign a simple numeric value for position, and tweak its effect in the equation, like
bq. urgency.uda.state.coefficient=(12 + (#{pos}state * 0.25))
and each time the "state" was incremented, the urgency would increase. An even better example of this is the proposed migration of priority from build-in, to UDA. It will be (default) a string type with constrained values of "L,M,H", so then it will need something like
bq. urgency.uda.priority.coefficient=(#{pos}priority * 5)
or some such thing, resulting in L = 5, M = 10, and H = 15, To have pri:L affect a negative coefficient, you could get L = -5, M = 5 and H = 15, with something like
bq. urgency.uda.priority.coefficient=(((#{pos}priority - 2) * 10) + 5)
The built-in "tags" coefficient applies if the task has one-or-more tags, but
bq. urgency.tags.coefficient=(4 + #tags)
would mean a coefficient of 5 for one tag and 10 for six tags, which makes sense.
Projects can be broken down into sub-projects with a "." separator, as in project.sub.subsub.subsubsub etc. This suggests a hierarchy of descending importance. The number of levels in a project could be used as a handle, with something like
bq. urgency.project.coefficient=(12 - (#{lev}project * 2))
where a top-level project will score 10 and a 6th level sub-project a zero.
I'm sure you can think of cases where this would be beneficial, and you can probably also see the giant can-o-worms next to it, mmmm worms..
Migrated metadata:
Created: 2012-08-19T20:28:33Z
Modified: 2017-01-16T18:25:51Z
Sitaram Chamarty on 2014-01-26T07:43:15Z says:
a different way of looking at this...
I think if we went that far, things could be even more simplified. Instead of the current:
urgency.age.coefficient=2.0 urgency.due.coefficient=12.0 urgency.next.coefficient=15.0 . . .
you could have
urgency.1.coefficient=age * 2.0 urgency.2.coefficient=due * 12.0 urgency.3.coefficient=next * 15.0 . . .
That is, treat everything as a variable. (If it's a number, use it as is; else use 1 if it is present and 0 otherwise, etc).
And of course you don't even need a dozen of them; we're just keeping them separately for the human to understand!
This wouldn't directly help what I am asking for in #1502 though; you'd still need to define syntax that says "sum of urgencies of all tasks that are dependent on this one", and this could get a little hairy.
David Patrick on 2014-04-15T14:07:58Z says:
need some way of attaching urgency scale to "date-proximity", where distant due-dates cause diminishing urgency coefficient.
Paul Beckingham on 2017-01-16T15:57:42Z says:
This needs a proper design. Making urgency calculations more dynamic is something that can be achieved with the proposed rules system, but has a significant performance cost.
David Patrick on 2017-01-16T18:25:51Z says:
rat bait?
This is something I have missed ever since I started using TW. My personal use-case includes a numeric UDA called "size" with values between 1-5, which is basically an estimate of how long a task will take. Since tasks with small "size" may be started later to be finished by deadlines, I would like this to be reflected in priority.
Judging by the name, an urgency "coefficient" seems like it should impact the urgency by coefficient * uda.value when the UDA is numeric. IMO this kind of minimal support for numeric UDAs would make a lot of sense, be easy-ish to implement, and would feel intuitive to users.
If someone can point me in the right direction, I'd be interested in taking a crack at this myself. Thanks.
As for solving my use case, I used the following inelegant .taskrc config:
uda.size.type=numeric
uda.size.label=Size
uda.size.default=3
urgency.uda.size.1.coefficient=-1
urgency.uda.size.2.coefficient=0
urgency.uda.size.3.coefficient=1
urgency.uda.size.4.coefficient=2
urgency.uda.size.5.coefficient=3
urgency.uda.size.6.coefficient=5