I have long been a fan of task management systems. When I was a student, I used Day Timer products a lot, and as the web came of age I tried many services: Remember the Milk, Nozbe, IQTell (may it rest in peace), and so on. As convenient as they were (usually) I found they all suffered from a combination of problems. Most were not flexible enough to keep the data I wanted. Most made entering tasks slower than it should be (something that someone proficient in an editor would notice). Some sites closed down; IQTell, in particular, closed after I had spent a month getting everything tweaked the way I wanted it.

I finally fell back on the one system I knew I could always rely on, would never close, and would be organized exactly the way I wanted: Org Mode. I have been using Org Mode for my task management system for a bit over a year now, so I'm documenting here how I have it set up. I will assume you are familiar with Org Mode already. If not, take a peek at Org Mode - Organize Your Life in Plain Text.

This will be a series of posts. For today I will go over the file structure I use: if you are already familiar with org-mode you will be able to replicate much of what I do.

Files

One of the first decisions you will need to make when you set up your org files is whether to have a bunch of files, one for each context, or One File to Rule them All. Having tried both, I found I preferred to have separate files. I have a "main" file called gtd.org, which I will talk about later, and one file for every context. For example, there is cs225.org and cs421.org for two of the classes I teach. There is ielite.org for a research group I am a part of. I have a subdirectory students/ where every student working on a project with me has their own file.

My main reasons for splitting the files by context are to prevent needing a top level header for everything (or else mixing unrelated projects and tasks together), and to keep the file sizes managable.

My file headers contain the TODO tags, a directive to have log drawers, and an agenda format string. The last item is the file tag. Here is the header for CS 225. 

#+SEQ_TODO: TODO(t) NEXT(n) STARTED(s) WAITING(w) DELEGATED(e) APPT(a) MAYBE(m) | DONE(d) CANCELLED(c) DEFERRED(f)
#+STARTUP: logdrawer
#+COLUMNS: %40ITEM(Task) %17Effort(Estimated Effort){:} %CLOCKSUM
#+FILETAGS: CS225

Each file has a subset of these top level headers:

  • Tasks
  • Projects
  • Someday/Maybe
  • Reference
  • Meetings
  • Appointments
  • Archived Tasks
  • Archived Meetings

## Meetings

I want to be able to keep track of meetings I go to, and especially meetings I am in charge of. For this, every agenda file has a top level header * Meetings

Each meeting has this structure: 

** <2018-09-11 Tue 10:00-11:00> Admin Meeting
*** Tasks
*** Agenda
*** Notes

The headline is level 2, contains a date stamp in the header itself. This causes it to appear in the agenda, and the agenda view automatically knows to remove the date when it displays the meeting.

If I am in charge of the meeting I will fill out the agenda, and have a task to email the agenda the day before. Tasks that arise during the meeting as a result of decisions get filed under the respective file-level task or project headings. The tasks here are only tasks directly related to running the meeting itself.

The reason I do this is because of a super convenient function org-clone-subtree-with-time-shift with default keybinding C-c C-x c. Set up the first meeting with the proper date stamps for the meeting and any tasks that will recur (like sending the agenda) and then duplicate it, shifting the dates into the future as you do so.

Appointments

An appointment is very much like a meeting, except that I don't expect to need to take notes or organize it. I use this for office hours.

Tasks

This heading is for all tasks that do not belong to a project. I use the SCHEDULED property to set a start date, and a DEADLINE for real deadlines. One thing I do differently than classic GTD is put a start date on all tasks (unless they are in someday/waiting). I learned this from the Manage Your Workday Now book written by Michael Linenburger I also like to have an effort property.

Projects

A project is just a list of tasks, but I insist that there be one task marked NEXT instead of TODO. There can be a header in the project for reference information if need be.

I'll talk more about task and project processing in a future article.

Archives

I do not like the way Org archives things in a separate file, so I am trying to keep a headline for archived tasks and archived projects. This may end up getting to bloated, but I haven't used this very long yet. Time will tell.

Next Actions!

There will be followup articles about other aspects of this. Currently I plan to write about the actual task workflow and the emacs lisp code I use with it.