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 -~----------~----~----~----~------~----~------~--~---
