You are already using REV2. Which has been around for 3-5 years.
First some comments then some news about REV3.
The depth of the outline really shouldn't come into play UNLESS
you use the WEEKLY GOAL setting. The weekly goal applies
a HUGE boost and that does cascade down because that's
the original design intent. It was the HOLLY CRAP feature
to make something POP to the top.
If you don't use that weekly goal (never like that myself);
things inherit correctly; whenever someone has an outline
that is out of whack I usually find they have a item near the top
with aggressive importance or urgency which propagates
down a really deep tree. Which is what it was designed to do;
and it is simply a case that that user just didn't expect the impact
to be so strong. Lower the priority cascade down too but people
always see to over look LOWERing the importance to balance the
outline... any how I digress.
The boosting factor I'm speaking of is that we BOOST the priority
of tasks that are overdue; not like we do with weekly goals; but we
do exponentially increase as the moves past the due in 1 day mark.
****
REV 3 of the algorithm was just sent to Andrey; this is the first
redux in about 3-5 years.
****
I took a good long look at it and decided it was time to re-factor the
code.
I found a couple things I no longer liked, Remember when the
algorithm REV2 was last written you had to have both a start and a
due date they weren't optional.
When Andrey gave you the ability to have no start or no due date;
the algorithm could handle it BUT it was not optimized for those cases
by any means; In the end it did work just not like everyone thought it
should
Such is the problem with changing things because someone likes
purple instead of green... opinions are like.....and sometimes the
results aren't perfect.
Here's the enhancements
0) Made it faster never hurts to protect our PPC user's batteries.
1) Added the ability to turn off the over-due boosting via a
preference.
tasks will not use the more aggressive calculation when over due
if this is disabled. (consider it the "don't nag me if
procrastinate"
option)
2) Made it possible to have due and start date weighting factors of
ZERO
or to out right disable them.
3) Change the computations for the duedate=startdate condition.
When start=due now the start acts only as a snooze function
and only the due date calculation is used. Old logical / code,
was using the start <> due calculation but was convoluted so
bad that you couldn't tell when you read the code; and it only
threw things out of whack on very deep outlines.
4) Fixed the miss handling of the startdate with nodue date condition.
Startdate now acts a a snooze only; previously the algorithm
treated this by using the StartDate as the DUE date; this happened
when it became possible to have NO Due Date. Most people
assume no due date means finish this task some day but who
cares when; the algorithm is now designed to think that way about
this case as well.
5) Made some structural changes that make it much much
easier to adapt as MLO evolves in the future.
It's a pretty big write so it will take him a few days to look over
decide
if he likes it and then integrate it. Or it will take him 1 day;
sometimes
he's crazy fast.
I usually try not to give him code that requires him to change the
gui or the object model. This time I did both *gasp* so it might
take a bit of integrate and I have no insight into which version
if any will use this code. I did hack together a version that
should plug into the existing MLO version so he could do quick
beta testing with select users. If you get tapped to test it realize
that the testing would be desktop only and probably break
your PPC sync if you use it; so beware what you ask for.
ok that's all; I'm going back to pondering on how to create
AutoFocus and AutoFocus2 templates for MLO without
begging for 30 new features.... ok maybe 5 or 6.
..... See
http://www.markforster.net/autofocus-system/
http://www.markforster.net/blog/2009/6/27/autofocus-2-time-management-system-af2.html
and
http://www.markforster.net/forum/post/835234
On Jul 14, 3:59 pm, "Richard Collings" <[email protected]> wrote:
> Hi Bob
>
> Really interested in what you say about Rev2 trying to make depth in the
> outline less of a factor in the scoring process. This is my major hate in
> MLO - the way in which lower level items are automatically made more
> important than higher level items to the extent that it is often impossible
> to promote the higher level items in front of the lower level items -
> particularly if one has applied the Week priority boost. It causes me so
> many problems that I just don't use the MLO scoring.
>
> Is there anyway that this recursive boosting can be made optional?
>
> Thanks
>
> Richard
>
>
>
> > -----Original Message-----
> > From: [email protected]
> > [mailto:[email protected]] On Behalf Of ratz
> > Sent: 14 July 2009 5:32 p
> > To: MyLifeOrganized
> > Subject: [MLO] Re: Computed-Score Priority and Start Dates
>
> > The start date should effect the priority because MLO was
> > conceived to be a mini project management system and start
> > dates do matter in many instances.
>
> > We are looking at the weighting factors to see if setting
> > them to the minimum can gracefully remove them from the
> > computation all together. In the past that didn't work; rev 1
> > of the algorithm would get divide by zero errors; so the
> > weights let you tweak but not removed the effect of due
> > dates). Rev 2 is done differently and may handle that case;
> > just not something that was looked at; at the time. Rev 2 was
> > conceived to make the depth of the outline less of a factor
> > in the priority and to make sliders at the center as a
> > default possible; aka our focus was on that; not dates.
>
> > This is a recursive algorithm so putting IF gates into it to
> > handle special case causes exponential increases in the
> > computation overhead and slow the algorithm down. Not a big
> > deal on the PC side, but the PPC version this is a BIG deal
> > so we have to be careful about change. We can't just say "IF
> > john set this preference" then skip this step. We can do
> > parallel code branches but both have the problem that then
> > every option someone dreams up has a huge increase in the
> > size of the code or the or the speed of the code. Or in other
> > words it's really not as simple as it would seem....
>
> > If there is a graceful way to modify the algorithm we'll do
> > it; I think setting the slider to the minimums may work if we
> > modify existing branch checks in the code; we calculate the
> > weighting factor separate from everything else and then feed
> > it into the engine. I think we'll do something like. If the
> > startdate weight is at the lowest setting then only use the
> > due date weight formula in all cases; if both weighting
> > factors are zero then don't weight factor at all;
>
> > one key feature will get lost if we do that; if you zero out
> > the due date weight then you'll loose the special feature
> > that a task that is due in 1 day and less than 3 days
> > overdue; it gets a pretty major priority boast in the hopes
> > that you will either get it done and rescue it; or reschedule
> > it; this saves you from those time bombs that are hiding in
> > your list a page down. After 3 days the algorithm assumes you
> > are an optimist that lies to him/herself and it drops the
> > task back into a normal aging progression.
>
> > On Jul 11, 11:01 am, Timothee <[email protected]> wrote:
> > > It seems to me too, that Start Date shouldn't affect
> > priority. Can't
> > > anyone think of a reason it should? A scenario where it
> > makes sense
> > > to?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"MyLifeOrganized" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/myLifeOrganized?hl=en
-~----------~----~----~----~------~----~------~--~---
