Hi Everyone,
I would like to contribute my perspective on using GTD with Chandler. This
document is not exhaustively complete, and subject to change, but it might be
enough to be food for thought for others. In summary, I have adopted
essentially the model of GTD with Chandler usage promoted by Mimi on the Lists
in that Task-stamped Chandler items are used as "GTD-projects" and "GTD-Next
Actions" are listed in the body of the GTD-Project Chandler items and tagged
with a set of abbreviations to indicate GTD-Context. Additionally, I create one
Chandler item for each GTD-context, and in the body of these GTD-Context
Chandler items, I list those GTD-Next Actions that, though longer in expected
duration than two minutes, are nonetheless stand-alone; that is, they are not
associated with a GTD-Project. For how I came to this design, see below for the
section "My Chandler + GTD Odyssey". Note that I'm following the GTD definition
of a Project as anything requiring more than one Next Action.
GTD "Hard Landscape" & Doing Next Actions Related To GTD Projects
I treat the Dashboard collection as my GTD "Hard Landscape." I include only my
personal calendars and only other calendars of sufficient interest to me that I
consider them also to be inherently part of my Hard Landscape, even though for
other reasons and advantages the additional items are in separate collections.
I judiciously add my top priority "today" GTD-project items, "today" GTD-next
action items that are nottasks, and high priority items I've tagged with the
GTD @WaitingFor triage status. My goal is to keep my Dashboard very tidy to be
reflective of my hard landscape calendar and the GTD-project I am working on
Now. The notion of an empty inbox translates into a Dashboard Now section with
very few items, often only one GTD-Project. For example, I have a "c-Andre"
calendar collection that contains only event items, and at the moment this is
the only personal collection that appears in my Dashboard. Sometimes I also
include the Holiday calendar I subscribed to via icalendar. My other couple
dozen collections are set to Keep Out of Dashboard. As desired, I will drag and
drop a GTD-project item from my "Projects" collection to add it to my
Dashboard, removing it from the Dashboard when I am no longer working from its
list of Next Actions.
Doing & Reviewing Based Upon GTD-Context
Assiduously tagging all Next Actions in the bodies of GTD-Project Chandler
items and GTD-Context Chandler items provides a key advantage of being able to
display them quickly using Chandler's Find feature. For example, if I have the
energy to make calls and I have a phone, I will search for "@calls" and begin
to work from the search results list that Chandler will display. To review Next
Actions for which I'm waiting for someone or something to do something, I
search for "@WF" and go from there.
Collecting, Processing, & Organizing New Chandler Items
Here is my workflow for processing and organizing new things that have arrived
via email, whether items imported from Chandler IMAP folders or items from team
members with whom you're sharing work, and for new items created directly in
Chandler.
1. Receive event, task, or mail-only item through Chandler IMAP folders or
otherwise. As the built-in IN collection is always included in the Dashboard,
these new items will also appear in Dashboard collection. Or, create new item
directly in Chandler using your favorite method.
2. If present, remove mailness (Mail stamp) from the item.
3. As desired, leave the item as event-stamped (as having eventness) or add
eventness.
4. As desired, leave taskness, or add taskness.
5. If the item is reference material, set the item as a note-kind only by
removing as necessary any taskness or eventness.
6. As possible in the moment, update title and body of item as necessary, and
copy to appropriate personal collections.
6a. If there is more than one related next action, modify the title to
create a GTD-Project (I add a prefix of "p-"), and be sure, as David Allen
stresses, to add the very next physical GTD-Next Action to the body of the
GTD-project item and indicate the context required to do the next action.
Drag-and-drop the item to a dedicated "Projects" collection, and, if desired,
to other collections, for example, a GTD Area of Responsibility collection ro a
GTD Agenda collection. These collections are explicitly kept out of the
Dashboard.
6b. If there is one standalone next action, add the next action to the body
of the appropriate GTD-Context Chandler item. (I currently keep my context
documents in a dedicated "Contexts" collection.) This collection is explicitly
kept out of the Dashboard.
6c. If there is insufficient time, context, or energy to fully process and
organize the item, to complete the front-end processing, drag-and-drop the item
to a dedicated "GTD IN" collection. This collection is explicitly kept out of
the Dashboard.
7. IMPORTANT PART: Remove item from Dashboard
My personal triage workflow counts on being able to remove items from the
Dashboard. This is currently only possible if the item is not stamped as mail
and exists in a user collection that is set to not appear in the Dashboard, but
this is enough functionality to support my workflow.
My Chandler + GTD Odyssey
I would like to thank Mimi for her virtual coaching of me in my practice of
GTD. Let me explain. A few weeks ago when Mimi first posted a response to
Poojan's query about Chandler and GTD, and explained how to use Chandler items
as GTD-Projects, my initial reaction was disagreement and puzzlement. But old
dogs can learn new tricks it seems. As I began to think about my elaborate
response to Mimi's post, it became disconcertingly clear to me that I had
fallen off the proverbial GTD wagon. So, before posting to the thread, I
decided to rethink and verify my approach. In the end, rather to my surprise, I
came also to the design of Chandler items as GTD-Projects. The key insight for
me, the coaching, was the realization that I really was not defining discrete
GTD-Projects in my GTD-Processing and GTD-Organizing workflows. I had instead a
mountain of amorphous pseudo Projects-Next-Actions each as separate Chandler
Task items dispersed among an assortment of collections. As David Allen warns,
this type of situation can cause one to go numb in proportion to the vagueness
of the "do-ability" of the pile. Yup. The core problem was my my incomplete
implementation of GTD-Projects.
While using Chandler items for GTD-Next Actions, I needed a way to represent
GTD-Project. Collections, of course, it would seem, but in reality, it became
rapidly quite impractical to have several dozen to several hundred Chandler
GTD-Project collections (strictly following the GTD definition of Project as
anything requiring more than one Next Action). As a consequence, my Chandler
item-based Next Actions steadily lost their hard edges as I attempted to
capture "GTD-Project-ness" and "GTD-Next Action-ness" in Chandler items. I
experimented with using collections to group items by GTD-Context, but quickly
decided it just took too long (to me) to add new items to the appropriate
context collections, for example to both the @Home context collection and the
@WaitingFor context/status collection. Instead, I began to use various
abbreviations to essentially tag Next Action items with their context.
I found a path out of this morass when I noticed that in actuality over time my
set of collections had evolved into what GTD calls Areas of Responsibility (as
Mimi has described GTD collections). From there, I landed on Chandler items as
GTD-Projects with project next actions listed in the body of the project items
with the next actions prefixed by a consistent set of abbreviations for
context, for example (@WF). So, in my quest propose an alternative
implementation, I find myself very productively using the design Mimi has
posted. Thanks Mimi! :-)
Please let me know if you have any questions.
Thanks, Andre
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
