Am 07.08.2015 um 08:24 schrieb Dwight Arthur:
> [A task has no start date specified and has a due date of tomorrow. The
> user specifies start date of today and observes the change in ComputedScore]
> This use case involves a change which intuitively feels like it should
> have little if any effect on ComputedScore, however it would produce an
> enormous change because the "elapsed"variable is changing from infinite
> to zero.
That's why I proposed a bounded function that does not go to infinity
when the elapsed time goes to infinity. Rather it would be:
-infinity = 100%, today = 50%, +infinity = 0%.
Also, the weight factor for the start date contribution would be
normally lower than the one for the due date. Or maybe one could use a
completely different function for the start date contribution, or no
contribution at all: The main use of the start date field is to suppress
tasks that have not yet started in the todo views. So you will not see
tasks that will start in the future anyway. And for the tasks that have
already started, it does not matter much whether they have started a
week ago or just now, or whether they have no start date (i.e.
-infinity), and it is unclear which of them you want to boost.
> In my view, no task should be able to exceed this task's
> (urgency+dates) score, however in your scheme, a task with lower
> urgency and a future due date could do so.
You're completely right with the first part of your sentence, but my
scheme solves that issue that exists in the current implementation.
That's exactly why I want to change the linear function to a bounded
function, i.e. one that has an upper limit. The due date contribution
could then never surpass the other factors like importance and urgency
(as it is doing right now, not with an unset due date, but if the due
date is far enough back in the past!).
So the due date contribution should not be limited only in order to deal
with the "unset due date" issue, but it also makes sense in view of
general productivity principles, and because the other contributions to
the computed score are also limited.
> In my opinion, the only recommendation that would bring an actual
> resolutionto this issue would be if MLO implemented a computed-score
> API.
An API would mean I must implement it in my own plugin, and that for
every platform. Nobody would want to do that.
I guess what you have in mind is having a way to enter your own formulas
- however MLO would need to support some kind of scripting language and
this may be difficult to implement, i.e. a lot of work for the
developers and again few users who would really use that.
I think more pragmatically: Creating a computed score is always a
compromise, and it's particularly difficult to combine the two factors
urgency and importance into one priority scale ("Eisenhower Matrix"). So
nobody expects a "perfect" solution. However, every user wants to have
at least a "reasonable" solution and will be happy if the software
provides such a solution, so that as a user you do not need to think
about all the details we need to discuss right now. My complaint is that
the current solution is *not* reasonable, because the date contribution
is linear and thus unlimited, while the other contributions are limited,
and because a task with a due date of tomorrow is considered less
important than a task with no due date. By using a bounded (limited)
function for the date contribution, this could be easily fixed. The
exact shape of the function, whether it is hyperbolic, exponential or
quadratic is not so important. Only two factors should be configurable:
The vertical scale of the function (i.e. the weight of the date
contribution in relation to the other contributions) and the horizontal
scale, (i.e. how quickly the function descends, like over days or over
months). It would be easy to present these with two sliders in a way
that users can understand their effect:
- How large should the due date contribute to priority (0-100%)?
- How quickly should due tasks get priority (days, weeks, months)?
And you could still have an option "treat unset due date as due today,",
though I insist this is not the obvious configuration and should not be
the default.
-- Christoph