Re: SOMEDAY/MAYBE vs. low priorities

[Pete Phillips <pete@smtl.co.uk>]

>>>>> "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