From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pete Phillips Subject: Re: SOMEDAY/MAYBE vs. low priorities Date: Sun, 30 Dec 2007 22:44:33 +0000 Message-ID: <26163.1199054673@localhost> References: <20071230181116.GE20947@atlantic.linksys.moosehall> Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1J96th-0005zd-7U for emacs-orgmode@gnu.org; Sun, 30 Dec 2007 17:44:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1J96tf-0005xY-Op for emacs-orgmode@gnu.org; Sun, 30 Dec 2007 17:44:43 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1J96tf-0005xQ-84 for emacs-orgmode@gnu.org; Sun, 30 Dec 2007 17:44:43 -0500 Received: from mailhost.smtl.co.uk ([193.131.77.174]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1J96te-0004Zj-H0 for emacs-orgmode@gnu.org; Sun, 30 Dec 2007 17:44:43 -0500 In-reply-to: <20071230181116.GE20947@atlantic.linksys.moosehall> 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: org-mode mailing list >>>>> "Adam" == Adam Spiers writes: Adam> GTD methodology suggests having "someday" and "maybe" task Adam> buckets for things which you want to remember to do at some Adam> undetermined point in the future. Adam> So far I have implemented this in org-mode by using SOMEDAY Adam> and MAYBE keywords. However I have been deliberating whether Adam> in fact these states are simply low priorities in disguise, Adam> and whether as a result it would make more sense to use [#D] Adam> for "someday" and [#E] for "maybe", on the grounds that Adam> "someday" implies that you really do want to accomplish the Adam> task eventually, whereas "maybe" implies that you're not yet Adam> decided whether you care too much if it ever gets Adam> accomplished, and is hence lower priority than "someday" (and Adam> probably the lowest priority imaginable, in fact). I disagree. They are not priorities. In fact, David Allen doesn't put any store by priorities anyway. His view is that priorities are dynamic, not static, and that any priorities you set now will change tomorrow when you get into your office. I used to use a dayrunner, using the classical time planning priorities. In retrospect, it never really helped me (although it was clearly better than the totally ad-hoc way I used to manage things before!). In fact I think it makes things too complex. I find that the GTD approach of reviewing my projects on a regular basis, in conjunction with checking my diary for the next month, helps me decide what i should do next. It also reduces the workload in terms of having to re-prioritise. This is what DA says: "And daily to-do lists and simplified priority coding have proven inadequate to deal with the volume and variable nature of the average professional's workload. More and more people's jobs are made up of dozens or even hundreds of e-mails a day, with no latitude left to ignore a single request, complaint, or order. There are few people who can (or even should) expect to code everything an "A," a "B," or a "C" priority, or who can maintain some predetermined list of to-dos that the first telephone call or interruption from their boss won't totally undo." Now, you may or may not agree with this, but personally I would try to avoid using priorities *if you are using GTD methodology*. If you are using some other system, then it may work. However, GTD doesn't need priorities because (quoting DA again): "As I've said, you shouldn't bother to create some external structuring of the priorities on your lists that you'll then have to rearrange or rewrite as things change. Attempting to impose such scaffolding has been a big source of frustration in many people's organizing. You'll be prioritizing more intuitively as you see the whole list, against quite a number of shifting variables. The list is just a way for you to keep track of the total inventory of active things to which you have made a commitment, and to have that inventory available for review." Also in the book, he says that your priority is dependant on context, time, and energy available. So for example, you have an hour until a meeting, you are pretty knackered, and have a phone and computer available. Do you try to do the priority A item on your list ? What if your priority A item is to write your business plan for the year ? With an hour, and feeling knackered, you are probably better off dealing with a bunch of phone calls, or processing emails. What if you have 10 minutes ? What if you have an unbroken 8 hours ? The point about this is that your priorities change constantly, you don't have time to keep rearranging them, and you will make choices based on other factors other than the priority you gave an item a few weeks ago. In fact, you are likely to ignore the priority in the above situation, so save yourself the bother. Adam> - Priorities become truly orthogonal to workflow, e.g. if Adam> your workflow keywords are PROJECT, PROJDONE, NEXT, STARTED, Adam> WAITING, DONE etc. then you can mark any of these as Adam> someday/maybe priority. This is quite a big advantage AFAICS. Hmmm. I don't quite get how this works. Why mark something as a PROJECT? What is the difference between PROJDONE and DONE ? Let me briefly explain my system with a snippet of my org-mode file: * Projects ** ------A------ *** Annual Report DEADLINE: <2008-04-11 Fri> **** NEXT email tech staff for summary of main projects completed this year :Laptop: **** NEXT speak to finance accountant - need summary of years income :Phone:Office:Jason: **** NEXT Write annual report SCHEDULED: <2008-03-14 Fri> :Laptop: **** Email report off :Laptop: ** ------G------ *** Glove Friction testing **** DELEGATED Ask John to get 2 brands of gloves tested for friction data :Office:John: **** NEXT Check with John whether the test data is now ready :Office:John: **** WAITING [2007-09-12 Wed] Emailed Acme Corp to see if they are interested in commercial friction testing. :Laptop: **** Write paper for publication ** ------W------ *** SOMETIME write research bid for effect of gels on exam gloves **** Discuss with Sam or Jim. Basically, I have part of my file for Projects, and underneath that the two star levels are just letters, so that I can group all projects starting with that letter together (if you have dozens or hundreds of projects, this helps a *lot*. Projects are three stars, and tasks/next actions are underneath those. Anyway, with the basic structure out of the way, each task/NA may have a context associated with it (using org tags). So the next action of "speaking to the accountant" can be done over the phone, when I'm in the office, or when I actually see the guy (Jason). Some actions don't have an org-mode todo keyword. That means that I have not as yet decided to move on them. When I do my regular review, I check whether I am ready to associate a todo keyword with them. My main point here is that these should tell you the stage of this project or task. I use: "NEXT" "WAITING" "DELEGATED" "SOMETIME" "DONE" Either I need to do something (NEXT), or I have asked someone outside our lab for something, written a letter etc (WAITING), asked someone in the lab to do something (DELEGATED), done it (DONE) or decided I want to make a decision about this sometime in the future (SOMETIME). My contexts are for the different places where I can deal with my stuff. I then have my customised agenda searches set up so that for example, ^C-a-l will show me all NEXT actions with the context of Laptop, and ^C-a-L will show me *all* items which are labelled with the Laptop context. I use the ^C-a-l when deciding what to do next when I'm at my laptop, and ^C-a-L when I want to look at *everything* (DONE, SOMETIME etc). I also use DEADLINE for things that I want to appear in my agenda so I know when I have to have them done by, and SCHEDULED for things I hope to work on on a certain day. Adam> What do people think? Are there other pros/cons, and is there Adam> a clean solution to "generally" restricting TODO views to #C Adam> or higher priority? Hmm. I guess my answer to this is that there is a *different* solution. :-) Pete