Quote:
Originally Posted by whpalmer4
Ah, so in a paper-based GTD system done strictly by the book you would have waited until you did a weekly review to notice that a project was done, rather than observing you had come to the end of your list of next actions?
|
Indeed I don't see this as a problem, so allow me to clarify and summarize my objections once again:
First, it is conceptually untidy to categorize a project or group into a single context.
Second, I have a penchant for (re)viewing my actions grouped per context and filtered by "remaining". In this scenario, the new implementation will include my project and group titles as individual tasks to be completed. This is both redundant and misleading.
Overall, the user is now forced to adapt to the idiosyncrasies of the software, rather than the other way around.
Quote:
|
No offense intended, but when people start talking about things being "100% GTD-compliant" it makes it difficult to read the post due to all the eye-rolling going on, it's like trying to read on a roller-coaster :-)
|
Every little recess in the system has a psychological impact, so "anything goes" is not a constructive mindset.
Assigning contexts to projects runs contrary to both the spirit and the letter of GTD. "You can't do a project" (p. 155). I couldn't care less about the letter, but the ramifications in this case are non-negligible.