[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] AutOrg, and practice of GTD in a group

From: Sven Bretfeld
Subject: Re: [Orgmode] AutOrg, and practice of GTD in a group
Date: 27 Jun 2010 22:16:46 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Hi Hellekin

"Hellekin O. Wolf" <address@hidden> writes:

> On Wed, Jun 23, 2010 at 08:41:22AM +0200, Sven Bretfeld wrote:
>> The third level is for the physical actions of the project. As you see,
>> only the first has a todo keyword (NEXT). The others are dependent from
>> the first (cannot be done before the first is done) and have only a
>> context tag. My context tags include things like HOME, OFFICE, SHOPPING,
>> TRAIN etc. When the first NEXT action is done, the next NEXT action in
>> the list gains the NEXT todo keyword automatically; this is what the
>> TRIGGER property cares for. In that way my Agenda Views (defined as
>> NEXT/HOME, NEXT/OFFICE etc.) display only next actions that can be done
>> immediately. 
> *** I like the concept of "chained actions" and the TRIGGER property.
> Very smart, the auto-assignment to NEXT keeps you busy and focused,
> and saves a number of key-strokes.  
> But I guess that implies multiple NEXT items.  Do you maintain several
> of those, or one per project?  Maybe I'm wrong--I didn't even read the
> GTD book thoroughly yet--but I like having *one* NEXT action, so that
> I don't get stuck with too many "next" things.  I can understand one
> NEXT action per project, but several within a single project raises
> internal warnings.

I think one of the main points in GTD is splitting up a task into
multiple physical actions (potential NEXT steps) which can be done one
after another depending on the available time, energy level and context.
Usually they build up a procedural chain of actions that gradually bring
the project to fulfillment. Sometimes there are actions that don't form
part of the chain, because they can be done independently from previous
steps. I usually put these things at the end of the project's
action-list an give them the NEXT status right from the start. For
example, this weekend I made my flat secure for my 8 months old son who
just starts to crawl and touches every cable he can put his hands on:

* Family
** Secure the apartment for the baby       :PROJECT:
*** NEXT Buy items [0/4]                   :SHOPPING:
    - [ ] devices to secure power outlets
    - [ ] sticky tape
    - [ ] wire protecting sleeves
    - [ ] new screws for the baby's bed
    :TRIGGER:  chain-siblings(NEXT)
*** secure all power outlets [0/6]         :HOME:
    - [ ] living room
    - [ ] bathroom
    - [ ] sleeping room
    - [ ] child's room
    - [ ] corridor
    - [ ] kitchen
*** tie all cables with tape               :HOME:
*** fix the baby bed                       :HOME:
*** NEXT remove loose objects from small tables :HOME:

The project has 5 physical actions. Four of them are dependent: First I
have to buy what I need, then I can start working. So I buy the items
and tick them of in the list one after another as I buy them (C-c C-c in
such a list ticks the items and changes the number in the brackets).
After I have them all, I set "Buy items" to DONE. Then "secure all power
outlets" automatically gets the NEXT status, and so on.

As you see, the fifth item "remove loose objects from small tables" can
be done without buying anything. So I give it the NEXT status right from
the start. It's important to place this item at the end of the list, so
that it can't spoil the chain, if I give it the DONE status before the
chained list is complete. In fact, for Emacs the last item is part of
the chain, but that doesn't really matter in practice. All that could
happen, is that I clear the tables before I have finished the other
parts and set the fifth item to DONE. When I, then, set the "baby bed"
item to DONE, the "loose objects" will get NEXT status again (I'm not
quite sure if that really happens, I can't remember such a case).

D. Allen recommends that you make a brainstorm when you are planning a
project. What are the things I have to do in order to realize the plan?
With orgmode you can make brainstorming very easy, just type M-RET and
hack in what occurs to your mind. After that, sort the items into
(sequential or independent) physical actions, references and so on. More
often than not, your collection will still feature some items which are
not physical actions, but sub-projects. If you notice that, you have to
break them further down into physical actions. But, I think, you don't
have to be too dogmatic with that. "Fix the baby bed" in fact consisted
of more than one action (change screws, fix a certain plank, tie a
cushion), but I had them all in mind and I planned to do them all
simultaneously. So I didn't note them too accurately.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]