SOMEDAY/MAYBE vs. low priorities

SOMEDAY/MAYBE vs. low priorities

[Adam Spiers]

GTD methodology suggests having "someday" and "maybe" task buckets for
things which you want to remember to do at some undetermined point in
the future.

So far I have implemented this in org-mode by using SOMEDAY and MAYBE
keywords.  However I have been deliberating whether in fact these
states are simply low priorities in disguise, and whether as a result
it would make more sense to use [#D] for "someday" and [#E] for
"maybe", on the grounds that "someday" implies that you really do want
to accomplish the task eventually, whereas "maybe" implies that you're
not yet decided whether you care too much if it ever gets
accomplished, and is hence lower priority than "someday" (and probably
the lowest priority imaginable, in fact).

Pros:

  - Priorities become truly orthogonal to workflow, e.g. if your
    workflow keywords are PROJECT, PROJDONE, NEXT, STARTED, WAITING,
    DONE etc. then you can mark any of these as someday/maybe
    priority.  This is quite a big advantage AFAICS.

Cons:

  - By default org agenda TODO searches will operate on all TODO
    entries, regardless of priority.  This means that you'd have to
    customise every existing agenda view of TODOs to restrict to only
    priorities #A to #C, which would be very cumbersome.

What do people think?  Are there other pros/cons, and is there a clean
solution to "generally" restricting TODO views to #C or higher
priority?

Re: SOMEDAY/MAYBE vs. low priorities

[Eddward DeVilla]

On Dec 30, 2007 12:11 PM, Adam Spiers <orgmode@adamspiers.org> wrote:
> Pros:
>
>   - Priorities become truly orthogonal to workflow, e.g. if your
>     workflow keywords are PROJECT, PROJDONE, NEXT, STARTED, WAITING,
>     DONE etc. then you can mark any of these as someday/maybe
>     priority.  This is quite a big advantage AFAICS.
>
> Cons:
>
>   - By default org agenda TODO searches will operate on all TODO
>     entries, regardless of priority.  This means that you'd have to
>     customise every existing agenda view of TODOs to restrict to only
>     priorities #A to #C, which would be very cumbersome.
>
> What do people think?  Are there other pros/cons, and is there a clean
> solution to "generally" restricting TODO views to #C or higher
> priority?

The con would be less of an issue if there were a more generalized why
to exclude things from agenda.  Kinda how you don't have to tell
agenda not to show you 'done' items or items tagged ARCHIVE.  You
could add your someday priority.  I would consider it a general filter
that takes items out of agenda view unless explicitly overridden in a
query.  It would probably introduce a bunch of other issues though.

Edd

Re: SOMEDAY/MAYBE vs. low priorities

[Pete Phillips]

>>>>> "Adam" == Adam Spiers <orgmode@adamspiers.org> writes:

    Adam> GTD methodology suggests having "someday" and "maybe" task
    Adam> buckets for things which you want to remember to do at some
    Adam> undetermined point in the future.

    Adam> So far I have implemented this in org-mode by using SOMEDAY
    Adam> and MAYBE keywords.  However I have been deliberating whether
    Adam> in fact these states are simply low priorities in disguise,
    Adam> and whether as a result it would make more sense to use [#D]
    Adam> for "someday" and [#E] for "maybe", on the grounds that
    Adam> "someday" implies that you really do want to accomplish the
    Adam> task eventually, whereas "maybe" implies that you're not yet
    Adam> decided whether you care too much if it ever gets
    Adam> accomplished, and is hence lower priority than "someday" (and
    Adam> probably the lowest priority imaginable, in fact).

I disagree. They are not priorities. In fact, David Allen doesn't put
any store by priorities anyway. His view is that priorities are dynamic,
not static, and that any priorities you set now will change tomorrow
when you get into your office.

I used to use a dayrunner, using the classical time planning
priorities. In retrospect, it never really helped me (although it was
clearly better than the totally ad-hoc way I used to manage things
before!). In fact I think it makes things too complex.  I find that the
GTD approach of reviewing my projects on a regular basis, in conjunction
with checking my diary for the next month, helps me decide what i should
do next. It also reduces the workload in terms of having to
re-prioritise.

This is what DA says:

	"And daily to-do lists and simplified priority coding have proven
	inadequate to deal with the volume and variable nature of the
	average professional's workload. More and more people's jobs are
	made up of dozens or even hundreds of e-mails a day, with no
	latitude left to ignore a single request, complaint, or
	order. There are few people who can (or even should) expect to
	code everything an "A," a "B," or a "C" priority, or who can
	maintain some predetermined list of to-dos that the first
	telephone call or interruption from their boss won't totally
	undo."

Now, you may or may not agree with this, but personally I would try to
avoid using priorities *if you are using GTD methodology*.  If you are
using some other system, then it may work. However, GTD doesn't need
priorities because (quoting DA again):

	"As I've said, you shouldn't bother to create some external
	structuring of the priorities on your lists that you'll then
	have to rearrange or rewrite as things change. Attempting to
	impose such scaffolding has been a big source of frustration in
	many people's organizing. You'll be prioritizing more
	intuitively as you see the whole list, against quite a number of
	shifting variables. The list is just a way for you to keep track
	of the total inventory of active things to which you have made a
	commitment, and to have that inventory available for review."

Also in the book, he says that your priority is dependant on context,
time, and energy available.  So for example, you have an hour until a
meeting, you are pretty knackered, and have a phone and computer
available. Do you try to do the priority A item on your list ? What if
your priority A item is to write your business plan for the year ? With
an hour, and feeling knackered, you are probably better off dealing with
a bunch of phone calls, or processing emails. What if you have 10
minutes ?  What if you have an unbroken 8 hours ?

The point about this is that your priorities change constantly, you
don't have time to keep rearranging them, and you will make choices
based on other factors other than the priority you gave an item a few
weeks ago. In fact, you are likely to ignore the priority in the above
situation, so save yourself the bother.

    Adam>   - Priorities become truly orthogonal to workflow, e.g. if
    Adam> your workflow keywords are PROJECT, PROJDONE, NEXT, STARTED,
    Adam> WAITING, DONE etc. then you can mark any of these as
    Adam> someday/maybe priority.  This is quite a big advantage AFAICS.

Hmmm. I don't quite get how this works. Why mark something as a PROJECT?
What is the difference between PROJDONE and DONE ?

Let me briefly explain my system with a snippet of my org-mode file:

* Projects
** ------A------
*** Annual Report  DEADLINE: <2008-04-11 Fri>
**** NEXT email tech staff for summary of main projects completed this year :Laptop:
**** NEXT speak to finance accountant - need summary of years income :Phone:Office:Jason:
**** NEXT Write annual report SCHEDULED: <2008-03-14 Fri> :Laptop:
**** Email report off :Laptop:
** ------G------
*** Glove Friction testing 
**** DELEGATED Ask John to get 2 brands of gloves tested for friction data :Office:John:
**** NEXT Check with John whether the test data is now ready :Office:John:
**** WAITING [2007-09-12 Wed] Emailed Acme Corp to see if they are interested in commercial friction testing. :Laptop:
**** Write paper for publication
** ------W------
*** SOMETIME write research bid for effect of gels on exam gloves 
**** Discuss with Sam or Jim. 

Basically, I have part of my file for Projects, and underneath that the
two star levels are just letters, so that I can group all projects
starting with that letter together (if you have dozens or hundreds of
projects, this helps a *lot*.

Projects are three stars, and tasks/next actions are underneath those.

Anyway, with the basic structure out of the way, each task/NA may have a
context associated with it (using org tags). So the next action of
"speaking to the accountant" can be done over the phone, when I'm in the
office, or when I actually see the guy (Jason).

Some actions don't have an org-mode todo keyword. That means that I have
not as yet decided to move on them. When I do my regular review, I check
whether I am ready to associate a todo keyword with them.

My main point here is that these should tell you the stage of this
project or task.  I use:

 "NEXT" "WAITING" "DELEGATED" "SOMETIME" "DONE"

Either I need to do something (NEXT), or I have asked someone outside
our lab for something, written a letter etc (WAITING), asked someone in
the lab to do something (DELEGATED), done it (DONE) or decided I want to
make a decision about this sometime in the future (SOMETIME).

My contexts are for the different places where I can deal with my
stuff.

I then have my customised agenda searches set up so that for example,
^C-a-l will show me all NEXT actions with the context of Laptop, and
^C-a-L will show me *all* items which are labelled with the Laptop
context. I use the ^C-a-l when deciding what to do next when I'm at my
laptop, and ^C-a-L when I want to look at *everything* (DONE, SOMETIME
etc).

I also use DEADLINE for things that I want to appear in my agenda so I
know when I have to have them done by, and SCHEDULED for things I hope
to work on on a certain day.

    Adam> What do people think?  Are there other pros/cons, and is there
    Adam> a clean solution to "generally" restricting TODO views to #C
    Adam> or higher priority?

Hmm. I guess my answer to this is that there is a *different* solution.

	:-)

Pete

Re: SOMEDAY/MAYBE vs. low priorities

[Adam Spiers]

Pete Phillips (pete@smtl.co.uk) wrote:
> >>>>> "Adam" == Adam Spiers <orgmode@adamspiers.org> writes:
> 
>     Adam> GTD methodology suggests having "someday" and "maybe" task
>     Adam> buckets for things which you want to remember to do at some
>     Adam> undetermined point in the future.
> 
>     Adam> So far I have implemented this in org-mode by using SOMEDAY
>     Adam> and MAYBE keywords.  However I have been deliberating whether
>     Adam> in fact these states are simply low priorities in disguise,
>     Adam> and whether as a result it would make more sense to use [#D]
>     Adam> for "someday" and [#E] for "maybe", on the grounds that
>     Adam> "someday" implies that you really do want to accomplish the
>     Adam> task eventually, whereas "maybe" implies that you're not yet
>     Adam> decided whether you care too much if it ever gets
>     Adam> accomplished, and is hence lower priority than "someday" (and
>     Adam> probably the lowest priority imaginable, in fact).
> 
> I disagree. They are not priorities. In fact, David Allen doesn't put
> any store by priorities anyway. His view is that priorities are dynamic,
> not static, and that any priorities you set now will change tomorrow
> when you get into your office.
> 
> I used to use a dayrunner, using the classical time planning
> priorities. In retrospect, it never really helped me (although it was
> clearly better than the totally ad-hoc way I used to manage things
> before!). In fact I think it makes things too complex.  I find that the
> GTD approach of reviewing my projects on a regular basis, in conjunction
> with checking my diary for the next month, helps me decide what i should
> do next. It also reduces the workload in terms of having to
> re-prioritise.
> 
> This is what DA says:
> 
> 	"And daily to-do lists and simplified priority coding have proven
> 	inadequate to deal with the volume and variable nature of the
> 	average professional's workload. More and more people's jobs are
> 	made up of dozens or even hundreds of e-mails a day, with no
> 	latitude left to ignore a single request, complaint, or
> 	order. There are few people who can (or even should) expect to
> 	code everything an "A," a "B," or a "C" priority, or who can
> 	maintain some predetermined list of to-dos that the first
> 	telephone call or interruption from their boss won't totally
> 	undo."
> 
> Now, you may or may not agree with this, but personally I would try to
> avoid using priorities *if you are using GTD methodology*.  If you are
> using some other system, then it may work. However, GTD doesn't need
> priorities because (quoting DA again):
> 
> 	"As I've said, you shouldn't bother to create some external
> 	structuring of the priorities on your lists that you'll then
> 	have to rearrange or rewrite as things change. Attempting to
> 	impose such scaffolding has been a big source of frustration in
> 	many people's organizing. You'll be prioritizing more
> 	intuitively as you see the whole list, against quite a number of
> 	shifting variables. The list is just a way for you to keep track
> 	of the total inventory of active things to which you have made a
> 	commitment, and to have that inventory available for review."
> 
> Also in the book, he says that your priority is dependant on context,
> time, and energy available.  So for example, you have an hour until a
> meeting, you are pretty knackered, and have a phone and computer
> available. Do you try to do the priority A item on your list ? What if
> your priority A item is to write your business plan for the year ? With
> an hour, and feeling knackered, you are probably better off dealing with
> a bunch of phone calls, or processing emails. What if you have 10
> minutes ?  What if you have an unbroken 8 hours ?
> 
> The point about this is that your priorities change constantly, you
> don't have time to keep rearranging them, and you will make choices
> based on other factors other than the priority you gave an item a few
> weeks ago. In fact, you are likely to ignore the priority in the above
> situation, so save yourself the bother.

Thanks a lot for the feedback.  I have read the book several times but
it was great to be reminded of his views on priorities.  Having said
that, I think I would really struggle to review on a regularly basis
without some kind of prioritisation, since at the time of writing I
have 324 NEXT actions and 82 PROJECTs.  Surely that's way too many to
review all of them within the reasonable timeframe of a weekly review
(which I imagine would be 30-120 minutes)?  Likewise, with this amount
of "stuff" to deal with, I think I would struggle by using his
4-critera (context/time/energy available/priority) and 6-level (ground
to 50,000ft) models alone for deciding what to do next - and that's
even with having all the org-agenda-custom-commands already in place
for viewing tasks by context, time, and energy available.

So at very least I really need a good way of marking a huge chunk of
them as "someday/maybe" so that they don't clutter up the weekly
review but are still available for say, a monthly review.  And on top
of that, I need a way of marking a "someday" or "maybe" task/project
as already STARTED or WAITING etc., which is why I wrote:

>     Adam>   - Priorities become truly orthogonal to workflow, e.g. if
>     Adam> your workflow keywords are PROJECT, PROJDONE, NEXT, STARTED,
>     Adam> WAITING, DONE etc. then you can mark any of these as
>     Adam> someday/maybe priority.  This is quite a big advantage AFAICS.
> 
> Hmmm. I don't quite get how this works. Why mark something as a PROJECT?
> What is the difference between PROJDONE and DONE ?

DONE is for completed NEXT actions, whereas PROJDONE is for completed
projects: I will have to change several actions from NEXT to DONE
before I can change the containing PROJECT to PROJDONE.  However when
archiving completed projects, I wanted to maintain the distinction
between projects and next actions, which is why I didn't overload the
meaning of DONE.

> Let me briefly explain my system with a snippet of my org-mode file:
> 
> * Projects
> ** ------A------
> *** Annual Report  DEADLINE: <2008-04-11 Fri>
> **** NEXT email tech staff for summary of main projects completed this year :Laptop:
> **** NEXT speak to finance accountant - need summary of years income :Phone:Office:Jason:
> **** NEXT Write annual report SCHEDULED: <2008-03-14 Fri> :Laptop:
> **** Email report off :Laptop:
> ** ------G------
> *** Glove Friction testing 
> **** DELEGATED Ask John to get 2 brands of gloves tested for friction data :Office:John:
> **** NEXT Check with John whether the test data is now ready :Office:John:
> **** WAITING [2007-09-12 Wed] Emailed Acme Corp to see if they are interested in commercial friction testing. :Laptop:
> **** Write paper for publication
> ** ------W------
> *** SOMETIME write research bid for effect of gels on exam gloves 
> **** Discuss with Sam or Jim. 
> 
> Basically, I have part of my file for Projects, and underneath that the
> two star levels are just letters, so that I can group all projects
> starting with that letter together (if you have dozens or hundreds of
> projects, this helps a *lot*.

Doesn't isearch-forward/backward accomplish the same thing?

> Projects are three stars, and tasks/next actions are underneath those.

OK.  My setup is similar except that I allow for sub-projects -
projects within projects.  As a result, projects are not uniquely
identified by their star level, so I explicitly mark them with PROJECT
which means I retain the ability to do keyword searches on them.  This
also has the advantage that I can include items for reference within
the project as sub-headings, and they won't have a keyword so they
won't show up in searches.

> Anyway, with the basic structure out of the way, each task/NA may have a
> context associated with it (using org tags). So the next action of
> "speaking to the accountant" can be done over the phone, when I'm in the
> office, or when I actually see the guy (Jason).

Similar to what I do.

> Some actions don't have an org-mode todo keyword. That means that I have
> not as yet decided to move on them. When I do my regular review, I check
> whether I am ready to associate a todo keyword with them.
> 
> My main point here is that these should tell you the stage of this
> project or task.  I use:
> 
>  "NEXT" "WAITING" "DELEGATED" "SOMETIME" "DONE"
> 
> Either I need to do something (NEXT), or I have asked someone outside
> our lab for something, written a letter etc (WAITING), asked someone in
> the lab to do something (DELEGATED), done it (DONE) or decided I want to
> make a decision about this sometime in the future (SOMETIME).

Hmm.  So you have WAITING and DELEGATED both meaning that you cannot
proceed until an external action is completed by someone else - what's
the difference?  And what do you mean by "not as yet decided to move
on them"?  Is that waiting on an internal action to be completed by
yourself, or that you haven't decided what to do next (a la "stuck
projects", and will at the next review?

> I then have my customised agenda searches set up so that for example,
> ^C-a-l will show me all NEXT actions with the context of Laptop, and
> ^C-a-L will show me *all* items which are labelled with the Laptop
> context. I use the ^C-a-l when deciding what to do next when I'm at my
> laptop, and ^C-a-L when I want to look at *everything* (DONE, SOMETIME
> etc).
> 
> I also use DEADLINE for things that I want to appear in my agenda so I
> know when I have to have them done by, and SCHEDULED for things I hope
> to work on on a certain day.

Yep, almost identical here too.

>     Adam> What do people think?  Are there other pros/cons, and is there
>     Adam> a clean solution to "generally" restricting TODO views to #C
>     Adam> or higher priority?
> 
> Hmm. I guess my answer to this is that there is a *different* solution.
> 
> 	:-)

I think this is where I am currently struggling with GTD.  When I have
so many NEXT actions and PROJECTs, how can I manageably review them on
a weekly basis, and how can I make quick but reliable decisions
several times a day as to what to do next?

Re: SOMEDAY/MAYBE vs. low priorities

[Adam Spiers]

(More Structured Procrastination... ;-)

Adam Spiers (orgmode@adamspiers.org) wrote:
> And on top of that, I need a way of marking a "someday" or "maybe"
> task/project as already STARTED or WAITING etc., which is why I
> wrote:
> 
> > - Priorities become truly orthogonal to workflow, e.g. if your
> >   workflow keywords are PROJECT, PROJDONE, NEXT, STARTED, WAITING,
> >   DONE etc. then you can mark any of these as someday/maybe
> >   priority.  This is quite a big advantage AFAICS.

Here's another case study for treating someday/maybe as priorities
rather than as keywords; best illustrated by example:

    * PROJECT [#A] This is an urgent project
    ** but it's stuck since we don't have any NEXT actions yet.
    ** However we do have:
    *** SOMEDAY some ideas about what might need doing later on
    *** MAYBE here's another idea we're not sure about yet

    * SOMEDAY This is an unimportant project
    ** Our NEXT actions are still SOMEDAY/MAYBE actions
    ** so is it stuck or not?
    ** Technically yes, but do we care?
       since the whole project is only a SOMEDAY.
    *** SOMEDAY when the project comes alive, this becomes a NEXT
    *** MAYBE here's another idea we're not sure about yet

In the "someday" project above, notice how the distinction between the
unimportant project and its as yet unimportant subtasks is blurred.
That makes for inaccurate search results.  How would we configure
`org-agenda-stuck-projects' to get the desired results?

Now compare with:

    * PROJECT [#A] This is an urgent project
    ** but it's stuck since we don't have any NEXT actions yet
    ** of priority #C or higher.
    ** However we do have:
    *** NEXT [#D] some ideas about what might need doing later on
    *** NEXT [#E] here's another idea we're not sure about yet

    * PROJECT [#D] This is an unimportant "someday" project
    *** SOMEDAY when the project comes alive, this "someday" action becomes a NEXT
    *** NEXT [#D] or we could mark it like this
    *** NEXT or even this, which would appear in searches for unprioritised items
    *** NEXT [#E] here's another "maybe" idea we're not sure about yet

I don't really know what's best, but hopefully this is all food for
thought.

Happy New Year to all!

Adam

Re: SOMEDAY/MAYBE vs. low priorities

[Adam Spiers]

Adam Spiers (orgmode@adamspiers.org) wrote:
> OK.  My setup is similar except that I allow for sub-projects -
> projects within projects.  As a result, projects are not uniquely
> identified by their star level, so I explicitly mark them with PROJECT
> which means I retain the ability to do keyword searches on them.  This
> also has the advantage that I can include items for reference within
> the project as sub-headings, and they won't have a keyword so they
> won't show up in searches.

OK, last one of the year honest!  `org-stuck-projects' appears to get
confused by sub-projects.  If I set it to

  ("/PROJECT" ("TODO" "NEXT" "NEXTACTION" "STARTED") nil "")

then in the following, it considers both the main and sub- projects as
unstuck, when in fact only the sub-project is:

  * PROJECT main project
  ** NEXT main project is not stuck
  ** PROJECT sub-project
  *** sub-project is stuck

Re: SOMEDAY/MAYBE vs. low priorities

[Manish]

On Dec 31, 2007 10:45 PM, Adam Spiers <orgmode@adamspiers.org> wrote:
> Adam Spiers (orgmode@adamspiers.org) wrote:
> > OK.  My setup is similar except that I allow for sub-projects -
> > projects within projects.  As a result, projects are not uniquely
> > identified by their star level, so I explicitly mark them with PROJECT
> > which means I retain the ability to do keyword searches on them.  This
> > also has the advantage that I can include items for reference within
> > the project as sub-headings, and they won't have a keyword so they
> > won't show up in searches.
>
> OK, last one of the year honest!  `org-stuck-projects' appears to get
> confused by sub-projects.  If I set it to
>
>   ("/PROJECT" ("TODO" "NEXT" "NEXTACTION" "STARTED") nil "")
>
> then in the following, it considers both the main and sub- projects as
> unstuck, when in fact only the sub-project is:
>
>   * PROJECT main project
>   ** NEXT main project is not stuck
>   ** PROJECT sub-project
>   *** sub-project is stuck
>

I am a very new org user so it may not make much sense but I suspect
tags could be used to mark some projects/tasks as SOMEDAY and then
stuck projects configured to ignore those?

Happy New Year!
-- 
Manish

Re: SOMEDAY/MAYBE vs. low priorities

[Pete Phillips]

>>>>> "Adam" == Adam Spiers <orgmode@adamspiers.org> writes:

    Adam> Thanks a lot for the feedback.  I have read the book several
    Adam> times but it was great to be reminded of his views on
    Adam> priorities.  Having said that, I think I would really struggle
    Adam> to review on a regularly basis without some kind of
    Adam> prioritisation, since at the time of writing I have 324 NEXT
    Adam> actions and 82 PROJECTs.  Surely that's way too many to review
    Adam> all of them within the reasonable timeframe of a weekly review
    Adam> (which I imagine would be 30-120 minutes)?  

I have over 200 projects, and goodness knows how many next actions.  I
can do the weekly review in about 2 hours, sometimes 3.

I work my way through each project, expanding it up fully, have a quick
glance, at everything. If I have been maintaining the project as I do
tasks during the week, then there shouldn't be much tinkering with
tasks. Collapse that project and move onto the next. 

I check my org agenda for the next month before I review the
projects. As I go through the projects, I therefore know what meetings,
deadlines etc I need to deal with, and whether there are days I need to
schedule to deal with certain tasks. 

Any SOMETIME projects will get the once-over and I will make a decision
as to whether I need or *want* to start to do anything on this. If not,
leave it as it is. 

However, the key thing is to make sure you are happy you have identified
the NEXT ACTION. With 324 of these to do, you are probably only going to
get 10-50 done in the next week. That means lots of these projects and
actions are going to get the quick scan from you, ensure you are happy
with the NA, and move on. Sometimes you will find that you forgot to
change the status of a task when you completed it, so you mark it as
done, decide the next action, and move on.

Don't forget that the weekly review is where you are planning your
strategy for the next week, so it is a good use of your time.

    Adam> So at very least I really need a good way of marking a huge
    Adam> chunk of them as "someday/maybe" so that they don't clutter up
    Adam> the weekly review but are still available for say, a monthly
    Adam> review.  

Well I look at ALL of my projects in the weekly review. For some of
them, I probably don't spend more than 2 seconds on them though, as they
are no brainers. 

An example.  At the moment I have

*** SOMETIME Defect Report - to include trust breakdown (need to edit the perl script) - just do last 12 months :Laptop:

This is a report I send out every 1/4, and someone once asked if we
could break it down by hospital reporters for the last 12 months. It is
probably 30-60 minutes perl programming for me, although my experience
is that sometimes a short programming task can expand! However, nobody
else has asked for it since, so when I see it I'm happy to move on. It's
been there for about 2 years.  I haven't got rid of it as I think it
would be a nice addition, and don't want to forget about it.

If you're anything like me, you probably have loads of similar projects
- people who ask for things because they think it is a good idea at the
time or ideas you have had which you don't want to forget about, but you
also don't want to do anything about at the moment. My view is that once
a week I am smart enough to decide whether I need to move on such
SOMETIME projects, because I also understand what the rest of my
workload is like, so am unlikely to make them current unless there is a
pressing need to do so.

So I agree with you about making many of them SOMETIME (or whatever todo
status works for you). You can do this in the comfort and knowledge that
once a week you will check them over, and decide if that is still the
appropriate status. I find that this is the only way to keep sane in
fact!  

The point I'm making here is that the weekly review shouldn't be a
mammoth issue just because you have lots of projects. Yes, the first
time may take a while (I fell off the GTD wagon earlier this year, and
it took me about 5 hours on the train to work my way through the whole
lot). List maintenance during the working day is vital to this.

    Adam> Hmm.  So you have WAITING and DELEGATED both meaning that you
    Adam> cannot proceed until an external action is completed by
    Adam> someone else - what's the difference?  

DELEGATED are things I can do something about - go and stand in front of
someone and ask why they haven't delivered.  WAITING is different - I
may be relying on someone's goodwill for example, or a reply from a
manufacturer, which probably needs a different way of moving it
forward. I find that it works for me.  YMMV

    Adam> And what do you mean by "not as yet decided to move on them"?

There are lots of things where, to paraphrase DA's words, 'there will be
a time in the future when I will be smarter, and able to make a decision
on this'. The example above is this sort of project - something I don't
want to forget about but I don't have the time or incentive at the
moment. However, a phone call from our paymasters asking for this in the
next report would move it onto the active list.

    Adam> Is that waiting on an internal action to be completed by
    Adam> yourself, or that you haven't decided what to do next (a la
    Adam> "stuck projects", and will at the next review?

I only use SOMETIME for something which is not yet active.  An internal
action which is to be completed by me would be marked as NEXT.  

I don't use the 'stuck project' concept myself.  Because GTD requires
checking each project regularly, you are making a conscious decision
about whether it has a NA or not.

    Adam> I think this is where I am currently struggling with GTD.
    Adam> When I have so many NEXT actions and PROJECTs, how can I
    Adam> manageably review them on a weekly basis, and how can I make
    Adam> quick but reliable decisions several times a day as to what to
    Adam> do next?

As I hope i explain above, I think the weekly review is manageable as
long as you have maintained the lists through the week.  Each day, I
scan my agenda buffer, check for appointments, SCHEDULED stuff or
approaching DEADLINES, and then generate the list for the appropriate
context (i.e., in the lab that would be NEXT actions for Office and
Laptop contexts). Looking at that list, it is usually clear to me what I
need to do. At this stage it is about making appropriate choices, based
on your gut instinct, or other knowledge (such as a phonecall you may
just have had, or an email). 

I also use the 48 folders concept, so my choice of task may also be
driven by what pops out of that days folder, or what turns up in my
in-tray.

Once I have decided what to do, I do it, then mark that task as done. At
the same time I will decide what the next task on that project should
be.  Then I look at the list again.

I have tried dabbling with priorities in org-mode, but they didn't work
for me. 

In your other post you say:

    * PROJECT [#A] This is an urgent project
    ** but it's stuck since we don't have any NEXT actions yet.
    ** However we do have:
    *** SOMEDAY some ideas about what might need doing later on
    *** MAYBE here's another idea we're not sure about yet

I would deal with this in a different manner. I don't use the
SOMEDAY/MAYBE (I'll call it S&M here for brevity!) status for active
projects. If a project is active, and there are some ideas I have, I
just give them a child header with no status and no context. Then I know
they won't pop up on any of my context lists, but I will scan them in my
weekly review.

So my version would probably look something like this:

    * PROJECT This is an urgent project  DEADLINE: [XXXX-XX-XX XXX]
    ** some ideas about what might need doing later on
    ** here's another idea we're not sure about yet

In the weekly review, I would then make sure I added a NEXT action.

For this example:

    * SOMEDAY This is an unimportant project
    ** Our NEXT actions are still SOMEDAY/MAYBE actions
    ** so is it stuck or not?
    ** Technically yes, but do we care?
       since the whole project is only a SOMEDAY.
    *** SOMEDAY when the project comes alive, this becomes a NEXT
    *** MAYBE here's another idea we're not sure about yet

If the project is a SOMEDAY, then you should not have any NEXT actions
associated with it. You may have a list of actions you would take if you
decided to move on this, but until the project moves off your SOMEDAY
list, there should be no NEXT actions. Honestly.

Mine would be something like:

    * SOMEDAY This is an unimportant project
    ** this would be the first step  
    ** probably want to talk to these people
    *** Jim
    *** John
    *** Sarah

So, happy new year to you all.  Best wishes for a well org-anised New
Year!

Pete