Getting Things Done with Remember the Milk

2010-01-01

Getting Things Done with Remember the Milk

I’ve been using Remember the Milk to help me get things done for over a year now. Recently, I wanted to make the application work better for me while getting back to some of the basic principles of GTD. To start out, I read some of the GTD-inspired posts on the Remember the Milk forum, in particular one by klketom. Through a little trial and error, I came up with a set of tags, dynamic lists, and a process that I’m quite happy with.

To collect

I collect tasks on the Inbox list. This is where tasks go that I send from email or Twitter (through a direct message). When I add tasks directly through the web or iPhone client, I usually organize them right away. Of course, potential tasks also pile up on my desk, in my memory, and on paper notes.

To process

As I process the stuff of my life, I move all clear tasks to RTM. Anything that doesn’t need follow-up I file away or toss out. I add notes to tasks, to be sure I remember why I want to do the task. I add a link to any supporting documentation.

Processing rules include:

• New tasks get assigned to a project or a duty.
• Due dates are for committed tasks, not just random dates. I can, of course, commit myself to a date, without anyone else involved.
• Do the Now list today.
• Do the Next list as time allows.
• Every project has at least one next task (_next).
• Every project tag has one item on the Projects list; these main project tasks reflect the outcome of the project.
• Every project has a due date.
• Due dates are for real, dated commitments. Do not use them simply to mark next tasks.
• Top priority indicates tasks that are not committed but that I want to do right away. This lets me add tasks to the Now list without making spurious deadlines.
• Lower priority tasks get added to the Next list, making them equivalent to next tasks. I know, the markup is redundant; I might not need the _next tag. In practice, I tend to use the _next tag for task sequences, as in projects, while I use priority for duties unrelated to other tasks.

To organize

Static lists reflect the immediacy of actions to take. The lists are static because it takes a deliberate action by me to put tasks on one of them, and a task can be on only one static list at a time.

• Inbox, for new tasks to tag & process; list should be empty after daily processing.
• Tasks, for everything to do that is not on another static list; in other words, these are active tasks that are ready to get done.
• Projects, for current projects; this is really a metalist, or a static list of tasks that each represent a dynamic list of tasks.
• Someday, a holding tank for bright ideas; these tasks are not planned to get done anytime soon.
• Waiting, a holding tank for next steps that I can’t take until an event happens over which I have no control; for example, I’m waiting for a response from someone.

Dynamic lists reflect current work lists based on next actions. The lists are dynamic because based on search criteria [in brackets below]. The application automatically includes only outstanding tasks in searches, so I don’t have to filter on completion status.

• Now, a high priority work list of things to do right away. The search picks up any outstanding task that is due within the next three days, is overdue, or has top priority. [(dueBefore:"3 days" OR priority:1)]
• Next, a work list of upcoming deadlines & next actions; priority is an alternative to next action, especially for duties. The search picks up any outstanding tasks that are due within a week, are next actions, or have priority, except for tasks on the Now list. [(dueWithin:"1 week" OR tagContains:_ OR (NOT priority:none)) NOT (dueBefore:"3 days" OR priority:1)]
• 😮—the oh list, a set of tasks that need prioritization; I go here when I need more to do or when doing weekly review. The search picks up active tasks that have no priority or due date, with the exception of next actions or errands.  [(list:Tasks AND priority:N AND due:never) NOT (tagContains:_ OR tagContains:@errands)]
• 😦—the sad list, for unprocessed tasks, as a safety net for tasks that might slip through the cracks; in review, I clean up anything on this list. The search picks up tasks with no tag, no project, or no duty (in other words, no reason to do them), along with tasks that somehow I’ve tagged as a goal but put on the Someday list; the search excludes errands, which I consider doing whenever I’m out and about. [isTagged:false OR NOT (tagContains:. OR tagContains:+ OR tagContains:@errands) OR (tagContains:gtd-soon AND list:Someday)]

Tags are the drivers behind the dynamic lists. I avoid tagging tasks with keywords that have no corresponding dynamic list.

• Projects get tagged with a period (.); for example, .renovation. Every task related to a project gets tagged, including the task on the Projects list. I define a project as an outcome (as listed on the Projects list) with a due date & multiple related tasks.
• Duties get tagged with a plus sign (+); for example, +citizen. Semantically, duties are any of the many roles I play in society. Many recurring tasks are related to duties.
• Next tasks get tagged with an underscore (_) or gtd-soon. The former is all-purpose; the latter, reserved for explicit goals coming out of GTD review & planning.
• Contexts get tagged with an at sign (@); for example, @phone. Contrary to the precepts of GTD, I do not use contexts profusely to organize tasks, because my GTD system for work is separate. In addition, almost everything I do is on line. Contexts are especially useful for grouping tasks when the active lists get long. I do not conflate GTD context with RTM location, also indicated by an at sign but separately implemented in the application.

Permalink