emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] Another GTD question.


From: Carsten Dominik
Subject: Re: [Orgmode] Another GTD question.
Date: Wed, 4 Oct 2006 18:11:26 +0200


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 address@hidden', address@hidden', 
address@hidden' 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]