The Drowning Syndrome
OK, let me continue my previous post.
As I said, and as TesTeq also said, people may fear (and often do fear, it seems) that they will overlook important things if they do not put them on their calendar. Now, that's a shame, isn't it. If even people who have wholeheartedly bought into the idea of staying "opportunistic" and make the best use of each moment (context, energy etc) do not dare to do so for fear that their important stuff will "drown" on long, daunting lists, then couldn't we (GTD adherents) agree that this is indeed a big problem? It is a particularly big problem since the "opportunistic" GTD paradigm is heavily and artfully contradicted by numerous other consultants and "philosophers" who argue strongly for the exact opposite. They claim that since time is the scarce resource it is if vital importance to allot time quotas, allow time slices etc and firmly book yourself into a straightjacket of a "calendar".
So I would advise DA to give some additional advice to his readers about how to avoid the "drowning syndrome" as far as undated tasks are concerned. If the two tricks I presented above (for paper and for computers) are of any help, I would consider them to be in the public domain (no royalties or recognition expected ;-) )
Let's move on to looking at the GTD reviewing process. In GTD the review is so much more than just the necessary "housekeeping". More importantly, the GTD reviewing is when you look ahead with your creative glasses on and find better avenues forward, for example "Would I reach my goal faster and with less effort if I started such and such a project and skipped those other ones?". That kind of reviewing is fun (at least I think so). In addition, in GTD the review takes an active part in the planning process and actually replaces certain elements that would have been necessary with other methods. By being able to fully rely on the fact that you will actively review your stuff reasonably soon you can leave out a whole lot of details. Bear in mind, that the more prevalent paradigm is to become "stress-free" by limiting the reviewing to just "housekeeping" and to accomplish this be "preprogramming" your lists with dates, fixed priority sequences, GPS locations etc - all you need to do thereafter is "obey" like a robot, no active situational decisions required. So GTD is significantly different, and many people seem to struggle with it. Again, I think the "drowning syndrome" is to blame.
DA does describe reviewing at all horizons, and I think there is nothing really wrong with the description, but for some reason - judging by my impression of discussions in many app forums - people often seem to understand the review as a tedious process where you go over all your context lists etc and almost fall asleep while doing so, and therefore also cannot be sure that you will observe everything.
In my own view, creative reviewing cannot be done context by context - the tasks are really out of context on the context lists [pun intended]. You need (at least I need) to view the tasks in the context of their Goals or AoRs or Projects etc. That's how the individual tasks get their meaning. That's where you can see if anything important is missing or if there is anything you can skip, any shortcuts you can take, anything you need to add.
Again (as in my previous post, there as regards "attention") reviewing is not so much of a problem if you use paper. You probably have all the tasks lists or whatever you need somewhere (project support) and keep only the barest minimum on context lists etc. But when you use a computer you often cannot organize and view your Goals, AoRs and Projects in a way that makes creative reviewing fun, comfortable and relaxing. You drown in lists. What I have found, and what I do one way or another (more or less elegantly depending on the app I am using at the moment), is organize my stuff hierarchically. Nothing complicated or super elegant - just like folders in Windows or in Google Drive. That helps a lot. And there are easy ways to improve this further. I am sure this whole topic is something DA could expand on in his teachings - how to avoid drowning by reviewing your stuff hierarchically.
Further, to avoid drowning in a long list of projects, I think a distinction between micro-projects ("tasks with subtasks") and "real" projects would be appropriate. I often hear people complain about "drowning" in a long list of "projects" where you cannot see the forest for all the trees. Needless to say, I personally do not keep all my "project" items all mixed up one one gigantic list - I use various workarounds to avoid it, depending on the app. I think DA and GTD could benefit from making a clearer distinction between "projects" of different "caliber".
And finally, people often seem to complain that with GTD their important tasks seem to drown among their less important tasks, which reduces their trust in their system. DA does not in any way say that all tasks are of equal importance or urgency - on the contrary, he stresses the opposite. But DA does advise strongly against putting tasks into predetermined fixed sequences for reasons of importance or urgency. Recklessly (if I may say so) he uses the word "priority" for all of this, and I'd say a clearer distinction (possibly using different words - importance, urgency and sequence) would alleviate a lot of the confusion surrounding "priority". Personally I do not use any form of neither priority-based nor date-based sequencing, but I do "flag" important/urgent tasks for convenient attention. Tasks that are important or are getting dangerously urgent (at least one of them higher than normal, and none of them low) I endow with a little red line on the left. (Have you guessed yet what the developer has chosen to call this coloring feature? ;-) )
Now, let me round this off by getting back to the matter of intellectual acceptance vs internalization. Some people simply do not even accept at the intellectual level the GTD view on dates and reviews. I suggest we forget about these people for the moment. But very many people (it seems to me) truly accept GTD at the intellectual level but find it hard to implement and fully rely on it as they understand it - generally for reasons that I have here summarized here as a feeling of "drowning". What I am suggesting is that in order to make the core GTD values internalized - through long, consistent, successful application - it is advantageous for everyone concerned if it can be explained intellectually how to avoid drowning in the first place.