Re: Another GTD question.

[Carsten Dominik <dominik@science.uva.nl>]

I really like this discussion started by Alex.
It has triggered for me a lot of
thinking and clarity about how to use Org-mode for a GTD system.  High
time, because my current system basically is "do whatever the closest
person pointing a gun to your head is asking".  Has kept me alive, if
stressed :-).

Charles Cave's [article/tutorial] gives a great overview over the basic
structure of GTD and his views on implementing GTD with org-mode.
Below are a few thoughts on how GTD elements can be represented in
org-mode.

2 The (too?) many organizational elements of Org-mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

There are many ways to apply structure to your notes using Org-mode:

- Categories (i.e. files)
- Lists (outlines)
- TODO keywords
- TAGS

and many of these can be used interchangeably.  For example, if I am
collecting the things I have to discuss with my colleagues Peter and
Sarah, I could

- use lists

: * Agendas
: ** Peter
: *** item p1
: *** item p2
: ** Sarah
: *** item s1
: *** item s2

- use TODO keywords

: #+TYP_TODO: Peter Sarah
:
: * Project X
: ** Peter item p1
: ** Sarah item s1
: * Project Y
: ** Peter item p2
: ** Sarah item s2

- use TAGS

: * Project X
: ** item p1          :Peter:
: ** item s1          :Sarah:
: * Project Y
: ** item p2          :Peter:
: ** item s2          :Sarah:

The same is true for contexts like `@work', `@home', `@computer' etc
as they are being used in GTD.  You could make a list of things to be
handled at your computer at home, or you could use tags for contexts.

So what is the best way to approach these issues, what method should
be preferred and why?  I think his is the core of the present
discussion.

For me personally, the main advantage of Org-mode is that I can keep
information relating to a project together in one place.  This is best
for many reasons, for example
- things that belong together, stay together
- easy review if a project is stuck

So I would not generally make lists for a specific contexts or people.
Lists for a specific person are unlikely as well.  Most of the time I
would use either TAGS or TODO keywords, also because the search
functions for tags and TODO keywords are the most powerful ones in
Org-mode.

3 CATEGORIES for broad splitting of the GTD system
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I am using separate files for things I need to do for HOME
and for WORK.  At work I use one big file for most things, but the
biggest tasks/projects I split off and put them into a separate file.

4 TAGS versus TODO keywords versus Lists to implement GTD elements
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


4.1 Context
===========

    I think most of us agree that contexts (location and required tools
    for doing a task) is something best implemented with TAGS in the
    org-mode system.  Tags like @home, @work, @phone, @computer, @mall
    can be defined and easily applied to any tasks that need that
    particular context.

4.2 The GTD lists as *status* of a task
=======================================

    Another important part of GTD terminology are different lists that
    contain tasks, for example NEXT ACTION, WAITING, or SOMEDAY/MAYBE.
    In the original GTD terminology these are called lists.  When
    thinking about implementation in Org-mode, it occurred to me that
    these are better called /status of a task/ which is then used to
    make corresponding lists.  Here is what I mean by status:

    - TODO: this is something that needs to be done, no further
      specification if this can be done now or not.
    - NEXT: this is something that can be done /now/, you have
      everything you need to start doing it.  This is what /next
      actions/ are about.
    - WAITING: This item cannot be done now, because we are waiting for
      something.  Somebody else needs to act, some material needs to
      arrive, etc.
    - SOMEDAY: means that you have not decided that this needs to be
      done.

    How should we go about implementing this structure in org-mode?

    1. We could make physically separate lists for each task status.
       As I said, I don't like this idea and will not discuss it
       further.

    2. We can use TODO keywords to implement these different states.
       Each time the state changes, we switch to a different TODO
       keyword.  This is very easy from an Agenda view: `1 t', `2 t',
       `3 t' etc directly switch to the corresponding keyword.  In the
       buffer, try `Shift-left/right' with the cursor on the keyword.

    3. We can use TAGS to implement this structure.  So each TODO item
       would have an additional tag, identifying the state of the task.
       - Advantage: you keep the simple on/off of a TODO item.
       - Disadvantage: When you mark an entry DONE, the NEXT tag (or
         whichever the current status is will stick around and put this
         item into your NEXT ACTION lists.

    Which of these two possibilities you choose really depends on your
    personal taste.  Since version 4.52 of org-mode matching TODO
    keywords has become as easy as matching tasks, so also from the
    technical point of view there is no preference. I am personally
    inclined to try option (2) first.

4.3 Agendas
===========

    Charles and Pete have already discussed here about making agendas
    (things to discuss with a particular person or group) either lists
    or tags.  I agree with them that it is best to keep tasks in the
    project context and use tags to produce the relation to a person.
    However, org-mode also gives you flexibility here.  Lets say you
    have to discuss a number of things with a person that is not
    related to projects, but for example to their and your personality,
    interaction with other people etc.  So you might want to sit down
    to write an agenda for discussing with them.  In this case, simply
    /also/ tag this special list with the name of the person/group.
    The a tag search will later link you to scattered items as well as
    the specific list you have drawn up.  For example:

    : * Agendas
    : ** Peter                               :Peter:
    : *** Issue 1
    : ** Sarah                               :Sarah:
    : *** Issue 1

5 Configuration of Org-mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~

5.1 Option 1: TODO items are simple two-state
=============================================

5.1.1 Configure by using in-file options
----------------------------------------

    : #+TAGS: { NEXT(n) WAITING(w) SOMEDAY(s) }
    : #+TAGS: Peter(P) Sarah(S)
    : #+TAGS: { @office(o) @home(h) @mall(m) }
    : #+TAGS: { @phone(p) @computer(c) }

5.2 Option 2: TODO types cover task lists
=========================================

5.2.1 Configure by using in-file options
----------------------------------------

    : #+TYP_TODO: TODO NEXT WAITING SOMEDAY DONE
    : #+TAGS: Peter(P) Sarah(S)
    : #+TAGS: { @office(o) @home(h) @mall(m) }
    : #+TAGS: { @phone(p) @computer(c) }

6 Creating the GTD lists
~~~~~~~~~~~~~~~~~~~~~~~~

With a system set up as described above, you can easily create all
those lists you need for GTD.  For the example below I am assuming
that we are using TODO keywords for the status of a task - if you are
using tags for this as will, just reformulate the search to match a
tag instead of a todo keyword.

- Next actions at home
   TAG search for "@home//NEXT"

- What actions am I waiting for that Sarah has to do?
   TAG search for "Sarah//WAITING"

- All items to discuss in a meeting with Sarah and Peter
   TAG search for "Sarah|Peter"

etc etc etc.