Feature Request: Due dates automatically set through dependencies
Michael Hopkins
library. I set return the book as dependent on reading the book so my
to-do list is clean. I also set for the return the library's due date
as the task's due date. Now, I would expect that since the final task
in the dependency would dictate the due date of all the tasks
depending on it, but MLO doesn't appear to agree.
Would it be possible for tasks leading to tasks with due dates to
"inherit" that final task's due date?
Enjoying the product very much!
Dmitry_N
approach.
The date on which you have to return the book doesn't depend on
whether you've done with the book or not, correct? :)
You just have to create 2 independent tasks but you will see "Return
the book" only on it's due date. "Read the book" will always be on the
list though.
Project: Book.
Task 1: Read the Book: daily at HH:MM
Sub-task 1: Return the Book if finished: no due date, but
dependent on Task 1.
Task 2: Return the Book latest: due date on DD:MM
On Nov 24, 10:19 am, Michael Hopkins <michael.hopk...@gmail.com>
wrote:
Michael Hopkins
Lisa Stroyan
I see what you're saying. Thanks!
Seriously, though, I do agree that they should be fairly independent. I tend to only read about 1/2 the books I get from the library. Before I started getting above mentioned emails, I would set a task "renew/return books by <date>" to start a day before the due date so it didn't show up until close to the actual due date. (One task for all books due on the same date). Then I usually would renew the books online if I was allowed (anything due on that date). As I read them I drop them off in our local drop-box.
Lisa
Lisa Stroyan, mailto:lstr...@gmail.com
www.empathic-parenting.com
Lisa Stroyan
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 mylifeorganiz...@googlegroups.com.
To post to this group, send email to mylifeo...@googlegroups.com.
Visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Mark
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...
m...@grantsmiths.org
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.
--
Mark
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....
Lisa Stroyan
Dwight
One other consideration: will any user need both kinds of date in a single outline? Or maybe even in a single task? I work on a certain complex proposal whenever I can, but the client meeting has a firm date. I could open my pool any time after mid - April but I have scheduled it for May 20th.
-Dwight
Mark
However, at the moment, if you try to use a dependency with a must be done by date, then you could miss the date if your not careful, since the dependent task has hidden it from view...
Maybe others have a different opinion??
Lisa Stroyan <lstr...@gmail.com> wrote:
Lisa Stroyan, mailto: ...@gmail.com