[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..