Hi Dwight, thanks for answering.
You're right, the terms "scheduled" and "feasible" describe the
difference in usage I have in mind, and yes, it also applies to the due
date, not only to the start date.
I also agree that the "feasible" approach is more in line with GTD, and
the "scheduled" approach more for strict project management where people
like to draw Gantt charts etc.
My problem is that I want to somehow have the best of both worlds, and
catch myself using the start date with different meanings. In
consequence, it makes matters worse since the dates lose a definite
meaning and don't help anymore in sifting through my task list.
So it's very important to define for yourself what your task properties
exactly mean, *and always stick to that meaning* if you want to enter
your tasks properly and then create meaningful views on them. I'm just
trying to find out what that meaning should be for me.
Another problem is that while you can of course choose your own meaning
for some properties, the software also makes tacit assumptions about
what they *should* mean and supports that meaning in several ways. In
this respect there *is* often a "right" meaning, namely the meaning that
the software author had in mind. If you start using it in other ways,
you start fighting against the software and cannot fully exploit its
features.
For instance, when I want to give the start date the meaning "first
feasible date", then setting it to today or leaving it empty would mean
exactly the same: "it's already feasible and can be started today".
However, the view "start next 7 days" shows only the tasks where I enter
a start date of today. Also, the computed score treats tasks with start
date of today and without start date differently (same for due dates).
So that goes counter to the usage as feasible dates, and it's something
I'm always struggling with in MLO.
-- Chris