From mboxrd@z Thu Jan 1 00:00:00 1970 From: Desmond Rivet Subject: Re: [off-topic/GTD]Only Next Actions list to rule them all ? Date: Wed, 21 Oct 2009 08:13:49 -0400 Message-ID: <87hbtthrlu.fsf@zinc.branchcut.ath.cx> References: <1e5bcefd0910202215n660589c9h65ffe5603b1bf8db@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N0a3A-0004Ot-W9 for emacs-orgmode@gnu.org; Wed, 21 Oct 2009 08:12:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N0a35-0004LZ-K4 for emacs-orgmode@gnu.org; Wed, 21 Oct 2009 08:12:20 -0400 Received: from [199.232.76.173] (port=57119 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N0a35-0004LQ-Bi for emacs-orgmode@gnu.org; Wed, 21 Oct 2009 08:12:15 -0400 Received: from relais.videotron.ca ([24.201.245.36]:39987) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N0a34-0001u6-Ua for emacs-orgmode@gnu.org; Wed, 21 Oct 2009 08:12:15 -0400 Received: from zinc.branchcut.ath.cx ([74.59.195.158]) by VL-MO-MR004.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KRV007TT5WDVF30@VL-MO-MR004.ip.videotron.ca> for emacs-orgmode@gnu.org; Wed, 21 Oct 2009 08:12:13 -0400 (EDT) In-reply-to: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Manish writes: > On Wed, Oct 21, 2009 at 10:45 AM, Marcelo de Moraes Serpa wrote: >> Hello list, >> >> This is for the GTD orgers out there. I've taken the article written by >> Charles as a basis for my GTD implementation. In the end, it's all about >> what works for you, but I'd like to get some insights/opinions from you: For >> Next Actions, are you using a single list OR you organize them >> hierarchically under each project (in the projects list)? >> >> I started with the second one, putting each next action (TODO) item under >> its correspondent project, however, it quickly became too bloated, and a mix >> of projects, sub-projects and next-actions. Of course, org helps there with >> sparse trees and other functions to filter trees, but still, I found it was >> too complex, albeit more specific and I did felt I was more "organized", >> even though I was getting lost. >> >> So, I just let go of my obsession about the perfect thing and decided to try >> a single Next Actions list, together with a Projects list. The next actions >> is a single list with all the actionable items from all the projects. I've >> lost the relationship between a next action item and a project, but I can do >> this easily by just looking at the action, having the system tell me is not >> that important. > > Usually, you define all actions for a project under the same hierarchy. You > can decide how you want actions to be designated "next" (and projects to be > designated "project") -- using keywords or tags and have a custom agenda > command collect the next actions for you from all agenda files in a single > list. I use a single file which contains both next actions (NAs) and projects, with NAs living under the relevant project. NAs have TODO state and tags for the contexts. Well, that's not 100% true. My GTD file contains NAs and a more generic concept which I'm calling "Categories", since a Category uses a CATEGORY property. Categories are just grouping items. Projects are a special kind of Category which a) have a TODO state (normal Categories do not) and b) tack a "p_" onto the beginning of the CATEGORY label and c) have a "project" tag. Basically a project is a Category that you can "finish" and which can be immediately identified as a project with a query (because of the project tag). In this way, NAs always live under a Category (I have a "Misc" Category to catch NAs which don't seem to fit anywhere else), and some Categories are projects. I don't nest Categories into sub-Categories, but I think I could do it - projects are just Categories with some extra TODO state and tags, and heading level doesn't really enter into it. Similarly, NAs are TODO items which do NOT have the project tag. When I collect all my NAs into an agenda view, I immediately see the CATEGORY label in the first column and I can see which NAs belong to a project and which don't, since I tacked a "p_" onto the Categories which represent projects. Also, my waiting list is defined as items in the WAITING state. I keep my someday list as a seperate file. -- Desmond Rivet Pain is weakness leaving the body.