[jlowen]

I have a particular re-occuring responsibility that I cant quite figure out the best way to capture it in OF. Help?

In my organization, I sent a weekly email out to all my members which give a rundown of important announcement and upcoming events. I typically send these each Monday, but think of things to add into the weekly newsletter almost every day. When I have these brainstorms I typically capture them into the inbox for later sorting. My question: Do I set up this weekly email as a project and add topic ideas as individual tasks, or is my weekly email a context like agenda: weekly update? If its a context then the topic ideas are just project-less actions? I am leaning towards the project route, with a context being "email" as that is the actual physical space I will use to generate the update. How would you do it?

[brianogilvie]

I wouldn't make it a context, because weekly update is not a place or a tool. I'd make it a parallel project. Put a couple of repeating tasks in it: "Draft weekly email" and "Revise and weekly email"; set the start and due dates appropriately and set each up to repeat from the assigned date. Then, each time you get an idea for the email, add it to the project. When you're ready to work on the email, you can focus on it and see all the items that you want to add.

I'd make the project parallel because OmniFocus adds new actions at the end of the project, and you don't want all your ideas to be blocked because the repeating weekly actions have not been done. And I would not make the project itself repeating, because then all the ideas you had for specific emails would also repeat.

If anyone else has a better idea for handling this kind of project, please post!

I believe your instinct is correct - go the project route. My reasoning is outlined below. (I realize you know all of this - I provide background so you can follow my thought process and perhaps point out an error in logic).

A. Givens (per GTD by David Allen):

- "Next Action" means the next physical, visible activity that would be required to move the item/situation towards closure. It must be descriptive of a physical behavior.

- "Project" means any outcome you are committed to achieving that will take more than one "next action" to complete.

- "Context" means either the tool, location, or person needed to complete the "next action".

B. Reasoning:

If we take a strict purist view, your weekly e-mail would not be a "context" as it is neither a tool, location, or person required to complete a "next action" (i.e not a project but a next action).

Again, from the purist view and using the above definitions, a topic idea would not be a "next action" as you may need to do a little research for a topic prior to writing it (internet search, call a colleague, etc.), or you may wish to outline it prior to writing, or you may wish to have someone review it before sending it out, etc. In other words - I suspect there may be several "actions" you are taking when preparing the weekly e-mail that are not being counted as "actions".

Given all of the above - I would set the weekly e-mail up as a project and the various topic ideas as "action groups" (i.e. actions with child actions) in OF (OF manual - page 13). Each "action group" could be the date of the next upcoming newsletter or the actual topic depending on your preference or need to cross reference. If a particular topic for a certain week can be written straight away with no intervening actions - then it will have no child actions for that week. In this way we maintain the "hard edges" in the GTD system.

We need these hard edges as "each represents a discrete type of agreement we have made with ourselves" (key point). If we allow the above definitions to blend to the point where they are interchangeable, then our mind tends to trust the system less and less and soon we find ourselves questioning why GTD is any different than making a "to-do" list. In my experience in reading various blogs and forums on GTD, many an experienced and new user of GTD get tied up in knots on handling certain issues because they are not maintaining an almost martinet vigilance to ensure they are not blending the above definitions.

Trust the above is of some help.

Aim Point

[curt.clifton]

I might handle this by creating a separate text file to hold ideas for the email. Then you could link to that file from the Draft Weekly Email action. As ideas come up, you can add them to the text file. Then the contents of the file would serve as the rough draft for the email when Monday rolls around.

There are a couple of ways to make it easy to dump info. into the text file. You could put an alias to the text file in an Active folder on the desktop. You could also use Quicksilver or LaunchBar (or Butler?) to append text to the file quickly.

If you prefer to keep everything in OmniFocus, then this probably isn't the best approach. But if you like to separate reference material from action items, then this separate file approach might be helpful. Food for thought anyway.

[brianogilvie]

Curt's suggestion is elegant. If you use Journler, MacJournal, DevonNote or DevonThink, Yojimbo, or some other snippet keeper with a quick entry or grab function, you could use one of them too.

And if you want to use OmniFocus's Quick Entry to capture ideas, but you don't want to make them part of the project, you could do the following: During your review, select all the relevant Inbox items, copy, switch to your text file or snippet keeper (or even email program, if you keep a draft of the next weekly email), paste them in, then switch back to OmniFocus and delete them.

Good luck finding a useful workflow!