From: Joshua Gilliland <joshuadgilliland@gmail.com>
To: emacs-orgmode@gnu.org
Subject: GTD methodology
Date: Wed, 23 May 2007 12:58:59 +0800 [thread overview]
Message-ID: <B09EED5C-5BCA-4E9F-9151-BC249D16E25B@gmail.com> (raw)
In-Reply-To: <46531442.7170eed4.68aa.ffffe5abSMTPIN_ADDED@mx.google.com>
Hi, everyone. After my email a couple of weeks ago asking about
Windows binaries with org-mode pre-configured, one of the members of
the list asked me to describe how I use org-mode to do GTD. It's been
a while since the request, but I haven't been able to get around to
writing this until now. I hope that the GTD-ers on the list will
find it useful, although I should mention that despite the fact that
I have been practicing GTD off-and-on for almost a year and a half, I
am still very bad at it. As such, some of my methods might not be
very "pure" GTD, so to speak.
I am more or less an adherent of the one-big-file method of GTD,
although I do keep separate someday/maybe and inbox files.
Basically, I use a combination of TODO status and tags to organize my
GTD in org-mode. For level one I have either projects or broad
categories (which are not projects in and of themselves but rather
umbrella categories under which many projects fit). Projects get
a :PROJECT: tag, while categories get no tag. I have my most
important categories and projects at the top of my document, with
everything else organized alphabetically.
Within each project, I keep tasks listed in the order in which they
must be completed. I tend to be a fairly disorganized thinker, so
this order (and the tasks themselves) change a lot. Each task is
given a tag, which identifies its context. For tasks that I can
complete in more than one context, I assign multiple tags. I used to
use an @anywhere task, but I have more or less abandoned it in favor
of this method.
I usually avoid tagging the later tasks in a particular project so as
to not clog up my context lists with tasks that I can't accomplish
yet. My general rule of thumb is that I do not tag a task with a
context until it is actionable.
I tend to be pretty weak at the concept of the first action; many of
my projects have more than one action that can feasibly be
accomplished right now. Because of this, I tend to have contexts
(i.e. tags) assigned to more than one task in most of my projects.
I use TODO status mainly for the nice feeling of being able to check
something off when I have finished, in addition to being able to
archive my completed tasks along with their contexts. I mainly use
TODO and DONE (I also have turned on logging so I know when I
completed a certain task). I also have WAIT, LATER, MAYBE, SOMEDAY,
and CANCELED statuses, although I don't really use them and I think
I'm going to get rid of some if not all of them (I might just keep
MAYBE). I used to have a NEXT status as well, but since I couldn't
figure out a way to filter by both context and NEXT status, I got rid
of NEXT altogether.
To get context lists, I usually use C-c \, since I know what most of
my contexts are. I also use the agenda command, and have assigned
agenda commands to all of my contexts, so that way I can occasionally
look at a list of my contexts to see if I'm forgetting about one (as
I said, I'm not very good at GTD).
During my weekly review, one of the things I do is move all someday/
maybe's to my someday/maybe file so as to keep things as clean as
possible in my GTD file. My someday/maybe file is an org file so
that I can keep it organized and yank things directly from my gtd.org
into it. My inbox is a plain text file so that I can add to it
through the magic of Quicksilver's "append" action (I'm sure many of
the other Mac users on the list know and love "append text..." as
much as I do).
That is basically my GTD methodology in a (very large) nutshell.
Hope it was useful. I have put a small sample org tree below to make
up for my poor abilities of description. Again, I apologize for the
length of this email. Brevity has never been a strength of mine.
Josh
------------------------------------------------------------------------
------------------------
#+TYP_TODO: TODO WAIT LATER MAYBE SOMEDAY CANCELED DONE
#+TAGS: OFFICE(o) HOME(h) COMPUTER(c) PROJECT(p) ERRANDS(e)
#+STARTUP: logging
* Email org-mode mailing list :PROJECT:
** DONE Write email to org-mode mailing list :COMPUTER:
CLOSED: [2007-05-23 Wed 12:27]
* Home
** Clean apartment :PROJECT:
*** TODO Buy broom :ERRANDS:
*** TODO Clean windows :HOME:
*** TODO Sweep floor
** Do laundry :PROJECT:
*** TODO Buy washing machine :ERRANDS:
*** TODO Throw out clothes that are beyond hope :HOME:
*** TODO Wash clothes
------------------------------------------------------------------------
------------------------
parent reply other threads:[~2007-05-23 4:59 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <46531442.7170eed4.68aa.ffffe5abSMTPIN_ADDED@mx.google.com>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B09EED5C-5BCA-4E9F-9151-BC249D16E25B@gmail.com \
--to=joshuadgilliland@gmail.com \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).