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] [mailto:[email protected]] On Behalf Of Mark Sent: Friday, May 17, 2013 2:10 AM To: [email protected] 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]. 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. -- 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.
