Urgency calculation incorrect for items with starting time today

[Michael]

Using MLO Windows 4.4.1 on Windows 10. Urgency calculation is erratic for items with a starting date today. E.g. I have a task with importance 100, Urgency 50, starting date yesterday 06:02; calculated urgency 0.998498128. If I postpone the starting date one day to today 06.02 (all other parameters the same), urgency increases to 1.032609654 whereas of course it should be less than with an earlier starting date. To me this seems to be a bug as it artificially increases urgency for items starting today (and it would strangely lead to a decreased urgency as a day goes by), but perhaps I misunderstand something? Any input would be welcome.

Thanks,

Michael

[Dwight]

Michael, the Users Guide has a long section about Computed Score which
gives a thorough discussion, with examples, showing exactly how all of
this is calculated. After reviewing this section you should be able to
calculate exactly how this 1.032609654 result was calculated and why. If
you precisely follow the algorithm as documented and get a different
result that may be evidence of a bug.

Disclaimer: this section is good at explaining why you got the result
you got; it is less effective at explaining how to get the resuly you want.

Disclosure: I do not personally use computed score because I was unable
to get it to do what I want, so I just ignore urgency and assign a 1-200
importance value; most of my to-do lists have importance as the last
(and sometimes only) sort.

-Dwight

On 10/10/2016 8:19 AM, Michael wrote:
> Using MLO Windows 4.4.1 on Windows 10. Urgency calculation is erratic
> for items with a starting date today. E.g. I have a task with importance
> 100, Urgency 50, starting date yesterday 06:02; calculated
> urgency 0.998498128. If I postpone the starting date one day to today
> 06.02 (all other parameters the same), urgency increases to 1.032609654

> whereas of course it should be /less/ than with an earlier starting

> date. To me this seems to be a bug as it artificially increases urgency
> for items starting today (and it would strangely lead to a

> /decreased/ urgency as a day goes by), but perhaps I misunderstand

> something? Any input would be welcome.
>
> Thanks,
> Michael
>

> --
> You received this message because you are subscribed to the Google
> Groups "MyLifeOrganized" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to mylifeorganiz...@googlegroups.com
> <mailto:mylifeorganiz...@googlegroups.com>.
> To post to this group, send email to mylifeo...@googlegroups.com
> <mailto:mylifeo...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/mylifeorganized.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/mylifeorganized/59567ab4-19f4-4b09-98c9-5c59d5e71ff3%40googlegroups.com
> <https://groups.google.com/d/msgid/mylifeorganized/59567ab4-19f4-4b09-98c9-5c59d5e71ff3%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Michael]

Thanks, Dwight. Even without making the exact calculation, this does not seem to follow the calculation as set out in the manual. Let's go through this step by step:

1. StartDateScore = (StartDateWeightFactor * Elpased) /500 (p. 49 of the manual). As time progresses, Elapsed increases. StartDateWeightFactor remains the same. Consequently, StartDateScore should increase as time progresses.
   
2. As there is only a starting date and no due date, DateScoreContribution = StartDateScore (p. 49 of the manual), so DateScoreContribution should increase as time progresses.
   
3. Score=(ImportanceScore * UrgencyScore) + DateScoreContribution (p. 50 of the manual). As all other parameters remain the same, only DateScoreContribution changes with progressing time, so Score should increase as time progresses.
   
4. However, as time progresses one day past StartDate, suddenly Score decreases by a considerable jump, and afterwards increases again.

In any case this would already be highly suspect as it means that there is a discrete change instead of a smooth transition. So as far as I can see, just based on basic math and simple logic, this seems to be a bug. However, I would like to see whether I make a conceptual mistake before contacting Andrey with a bug report. So please let me know if I am really overlooking something. Thanks!

- Michael

[Christoph Zwerschke]

Am 11.10.2016 um 16:51 schrieb Michael:
> so Score should increase as time progresses.

Yes, that should be the case.

> 4. However, as time progresses one day past StartDate, suddenly Score
> *decreases *by a considerable jump, and afterwards increases again.

That should in fact not happen. Note that the score also depends on the
score of the parent task - but that should only increase with time as
well, unless you changed some of its attributes. Also note that the
score is only computed when you're in a view that sorts by computed
score. Otherwise the values are not updated in the statistics.

So far I could not reproduce an erratic behavior in the way you
reported. However, I have two other grievances with the way start and
due day are used for computed score:

1) There are two possible interpretations of "start date":

a) Start date = the date when a task becomes feasible/doable. That does
not mean that you need to do it on that day, but that you can't do it
earlier. Not setting a start date means the task can theoretically be
tackled any time, even right now.

This is also how MLO interprets the date when determining "Active
Actions". Tasks with start date in the future are considered inactive.

However, when you use start date with this meaning, then it makes little
sense to factor it into the computed score. Since if the start date is
in the future, I don't see the task anyway in my list of actionable
items. And if it's in the past, I don't care how long it was in the past
or if a start date is set at all.

I solved this by setting the weight for "start date" to zero (moving the
slider to the left) in the "To-Do Ordering options". Now the "start
date" is not factored into the computed score at all.

b) Start date = the date when you plan/want to do the task, i.e. the
scheduled date for the task.

In that case, the MLO rule for "active actions" might bite you, because
you will see the task only when you scheduled it, even if you have time
and might want to do it earlier. So this makes only sense if you
schedule everything. But I like to leave things more open.

2) More serious, the problem with "due date".

Here my problem with the computed score is that tasks without a due date
get the same score as tasks with a due date of today.

In my opinion, tasks without a due date should get a lower date
contribution than all tasks with due date, because no due date to me
means "no deadline", "not urgent". Mathematically, they should be
treated like a task with due date +infinity, not like a task with due
date "today".

-- Christoph

[Christoph Zwerschke]

Am 11.10.2016 um 20:34 schrieb Christoph Zwerschke:
> That should in fact not happen. Note that the score also depends on the
> score of the parent task - but that should only increase with time as
> well, unless you changed some of its attributes.

Hm, just noticed that there is a case where it could actually decrease,
namely shortly after a task becomes overdue, if you set the "boost
overdue tasks" option. This is because the boost factor may be smaller
than 1 shortly after that (0.25 * remaining) in that case. So if the
parent task has a due date around that time, this might be the effect
you're seeing. Unfortunately, the help file does not say which time unit
is used for "remaining" (hours, days?).

By the way, I think there is also an error in the help file - it should
be "Remaining = DueDate - now" instead of "Remaining = now - DueDate".

-- Christoph

[Michael]

Thanks again, Christoph.

I have the increased priority for overdue tasks off, so that is not the issue either. So it looks as if this is a bug and I will send a message to Andrey.

Re your problem #2: I agree, and I think this is in general a symptom of the way MLO looks at tasks without due date; e.g. it is not possible to set recurrences based on start date (as opposed to due date) and it is in general impossible to set recurrences for tasks without a due date. In most methodologies (including GTD), tasks without due dates are an essential part, but MLO tends to ignore their specifics. It's as far as I am concerned the major weakness in what is still the best task management suite out there,

- Michael