Dwight, I get your point. I agree that the start could be seen in two ways, either possible to start or must start depending on your view, I use it for the 1st option. The due date, for me is about the same, whether its a must (hand in a report) or makes no sense after this date, to me does not make too much difference.
Maybe simply a checkbox to tell MLO how to treat the dates would be enough.... On Friday, 17 May 2013 13:32:54 UTC+2, Dwight Arthur wrote: > > Dates in MLO mean different things to different people. The most > intuitive meaning is that start date is when you schedule to start working > on a task and end date is when you schedule to finish it. A more > GTD-oriented meaning has start date as the first date on which it’s > possible or meaningful to work on a task, and due date as the last day on > which it’s possible or meaningful to do it. For example, if I fail to run > my backups tonight, the opportunity is gone. There’s no point in running it > twice tonight in an attempt to catch up. That makes tonight the GTD due > date. So I think we need four dates: GTD beginning, scheduled start, > scheduled end and GTD due. The interval between start and end should be > implemented as “duration” which is different from the interval between > beginning and due which is lead time. > > > > At this point, MLO has a lot of support in place for GTD beginning and due > dates. Many people are more interested in scheduled start and end, and > assign values to “start” and “due” as though they were schedule dates. It’s > fine to do this if it helps you manage your tasks, however you will run > into issue after issue where MLO does not have the logic needed to truly > support schedule dates. It would be a shame if schedule logic were added to > MLO without adding a separate set of dates as this would break the existing > ability to create and manage GTD dates. > > > > The proposal to have MLO change a due date based on dependencies makes > total sense if we were talking about scheduled end date. In addition, MLO > should change the scheduled end date if the total [remaining] effort is > greater than the interval between (later of TODAY or START) and End. I > believe that there are many user requests for better date handling, > calendar views, guessing when a series of tasks will complete, etc which > would be feasible if MLO implemented a four-date scheme. > > > > If we are talking about GTD dates, as MLO is currently implemented, this > proposal does not make sense. Here’s an example: An artist I’m following is > having an exhibit in Philadelphia from May 15 through June 30. I don’t have > to go but I would like to, I would like to add one of his more recent works > to my collection. My friend Joe is going to school in Philadelphia and is > leaving June 1 for a summer job in Vancouver. I would not drive to > Philadelphia just to see Joe but if I’m in town I’d like to see him and > maybe catch a meal together. So I create two tasks: Go to exhibit in > Philadelphia, GTD begin (start) date May 15, due date June 30. Get together > with Joe, begin May 15 end May 31, dependent on the exhibit task. It does > not follow from this that if June 1 arrives I can no longer go to the > exhibit, just that if I go in June it will be too late to see Joe. So > changing the due date for the exhibit to May 31 would have been a mistake. > > > > Current handling of due dates across dependencies is correct if the due > dates are intended as GTD due dates, i.e. the last date on which the task > can meaningfully be done. The enhancement you are discussing would be > valuable if the dates were intended as schedule dates, i.e. what date do I > plan on completing this task. In order to reduce confusion and open the > door for improved date-oriented functionality, MLO should implement start, > end and duration separate from begin, due and lead time. > > > > *From:* [email protected] <javascript:> [mailto: > [email protected] <javascript:>] *On Behalf Of *Mark > *Sent:* Friday, May 17, 2013 2:10 AM > *To:* [email protected] <javascript:> > *Subject:* [MLO] Re: Feature Request: Due dates automatically set through > dependencies > > > > Your correct it does not take into account the deadline, but it should. > In your example Task A should take a deadline you input that is earlier > than the 1st of June OR inherit the 1st of June as the final deadline if > there is no date input/or deadline after 1st June is input.... > > I checked an incomplete task, that the 'parent' is dependent on will cause > an overdue parent task to remain inactive and therefore hidden in the > active task list... > > On Wednesday, 15 May 2013 22:32:26 UTC+2, Andrew Garvin wrote: > > While I see the sense of the approach you suggested for Michael H's *specific > *example, it seems to avoid the larger question. > > Suppose that Task B is due on June 1 and that it is also dependent on (the > completion of) Task A (and all of A's sub-tasks, if any). > The dependency implies that Task A must be completed on or before June 1 > *even > though* completion of A by June 1 may *not* be a requirement of Task A > itself. In other words, it seems that Task A should inherit Task B's > deadline because of the dependency. > > Unless I'm really using MLO incorrectly, this deadline inheritance doesn't > seem to occur. Am I missing something? > > -- > 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 [email protected] <javascript:>. > To post to this group, send email to [email protected]<javascript:> > . > Visit this group at http://groups.google.com/group/mylifeorganized?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/mylifeorganized?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
