Re: [Orgmode] SOMEDAY/MAYBE vs. low priorities
> "Adam" == Adam Spiers <[EMAIL PROTECTED]> writes: Adam> Thanks a lot for the feedback. I have read the book several Adam> times but it was great to be reminded of his views on Adam> priorities. Having said that, I think I would really struggle Adam> to review on a regularly basis without some kind of Adam> prioritisation, since at the time of writing I have 324 NEXT Adam> actions and 82 PROJECTs. Surely that's way too many to review Adam> all of them within the reasonable timeframe of a weekly review Adam> (which I imagine would be 30-120 minutes)? I have over 200 projects, and goodness knows how many next actions. I can do the weekly review in about 2 hours, sometimes 3. I work my way through each project, expanding it up fully, have a quick glance, at everything. If I have been maintaining the project as I do tasks during the week, then there shouldn't be much tinkering with tasks. Collapse that project and move onto the next. I check my org agenda for the next month before I review the projects. As I go through the projects, I therefore know what meetings, deadlines etc I need to deal with, and whether there are days I need to schedule to deal with certain tasks. Any SOMETIME projects will get the once-over and I will make a decision as to whether I need or *want* to start to do anything on this. If not, leave it as it is. However, the key thing is to make sure you are happy you have identified the NEXT ACTION. With 324 of these to do, you are probably only going to get 10-50 done in the next week. That means lots of these projects and actions are going to get the quick scan from you, ensure you are happy with the NA, and move on. Sometimes you will find that you forgot to change the status of a task when you completed it, so you mark it as done, decide the next action, and move on. Don't forget that the weekly review is where you are planning your strategy for the next week, so it is a good use of your time. Adam> So at very least I really need a good way of marking a huge Adam> chunk of them as "someday/maybe" so that they don't clutter up Adam> the weekly review but are still available for say, a monthly Adam> review. Well I look at ALL of my projects in the weekly review. For some of them, I probably don't spend more than 2 seconds on them though, as they are no brainers. An example. At the moment I have *** SOMETIME Defect Report - to include trust breakdown (need to edit the perl script) - just do last 12 months :Laptop: This is a report I send out every 1/4, and someone once asked if we could break it down by hospital reporters for the last 12 months. It is probably 30-60 minutes perl programming for me, although my experience is that sometimes a short programming task can expand! However, nobody else has asked for it since, so when I see it I'm happy to move on. It's been there for about 2 years. I haven't got rid of it as I think it would be a nice addition, and don't want to forget about it. If you're anything like me, you probably have loads of similar projects - people who ask for things because they think it is a good idea at the time or ideas you have had which you don't want to forget about, but you also don't want to do anything about at the moment. My view is that once a week I am smart enough to decide whether I need to move on such SOMETIME projects, because I also understand what the rest of my workload is like, so am unlikely to make them current unless there is a pressing need to do so. So I agree with you about making many of them SOMETIME (or whatever todo status works for you). You can do this in the comfort and knowledge that once a week you will check them over, and decide if that is still the appropriate status. I find that this is the only way to keep sane in fact! The point I'm making here is that the weekly review shouldn't be a mammoth issue just because you have lots of projects. Yes, the first time may take a while (I fell off the GTD wagon earlier this year, and it took me about 5 hours on the train to work my way through the whole lot). List maintenance during the working day is vital to this. Adam> Hmm. So you have WAITING and DELEGATED both meaning that you Adam> cannot proceed until an external action is completed by Adam> someone else - what's the difference? DELEGATED are things I can do something about - go and stand in front of someone and ask why they haven't delivered. WAITING is different - I may be relying on someone's goodwill for example, or a reply from a manufacturer, which probably needs a different way of moving it forward. I find that it works for me. YMMV Adam> And what do you mean by "not as yet decided to move on them"? There are lots of things where, to paraphrase DA's words, 'there will be a time in the future when I will be smarter, and able to make a decision on this'. The example above is this sort of project - something I don't want
Re: [Orgmode] SOMEDAY/MAYBE vs. low priorities
On Dec 31, 2007 10:45 PM, Adam Spiers <[EMAIL PROTECTED]> wrote:
> Adam Spiers ([EMAIL PROTECTED]) wrote:
> > OK. My setup is similar except that I allow for sub-projects -
> > projects within projects. As a result, projects are not uniquely
> > identified by their star level, so I explicitly mark them with PROJECT
> > which means I retain the ability to do keyword searches on them. This
> > also has the advantage that I can include items for reference within
> > the project as sub-headings, and they won't have a keyword so they
> > won't show up in searches.
>
> OK, last one of the year honest! `org-stuck-projects' appears to get
> confused by sub-projects. If I set it to
>
> ("/PROJECT" ("TODO" "NEXT" "NEXTACTION" "STARTED") nil "")
>
> then in the following, it considers both the main and sub- projects as
> unstuck, when in fact only the sub-project is:
>
> * PROJECT main project
> ** NEXT main project is not stuck
> ** PROJECT sub-project
> *** sub-project is stuck
>
I am a very new org user so it may not make much sense but I suspect
tags could be used to mark some projects/tasks as SOMEDAY and then
stuck projects configured to ignore those?
Happy New Year!
--
Manish
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] SOMEDAY/MAYBE vs. low priorities
Adam Spiers ([EMAIL PROTECTED]) wrote:
> OK. My setup is similar except that I allow for sub-projects -
> projects within projects. As a result, projects are not uniquely
> identified by their star level, so I explicitly mark them with PROJECT
> which means I retain the ability to do keyword searches on them. This
> also has the advantage that I can include items for reference within
> the project as sub-headings, and they won't have a keyword so they
> won't show up in searches.
OK, last one of the year honest! `org-stuck-projects' appears to get
confused by sub-projects. If I set it to
("/PROJECT" ("TODO" "NEXT" "NEXTACTION" "STARTED") nil "")
then in the following, it considers both the main and sub- projects as
unstuck, when in fact only the sub-project is:
* PROJECT main project
** NEXT main project is not stuck
** PROJECT sub-project
*** sub-project is stuck
___
Emacs-orgmode mailing list
Remember: use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] SOMEDAY/MAYBE vs. low priorities
(More Structured Procrastination... ;-) Adam Spiers ([EMAIL PROTECTED]) wrote: > And on top of that, I need a way of marking a "someday" or "maybe" > task/project as already STARTED or WAITING etc., which is why I > wrote: > > > - Priorities become truly orthogonal to workflow, e.g. if your > > workflow keywords are PROJECT, PROJDONE, NEXT, STARTED, WAITING, > > DONE etc. then you can mark any of these as someday/maybe > > priority. This is quite a big advantage AFAICS. Here's another case study for treating someday/maybe as priorities rather than as keywords; best illustrated by example: * PROJECT [#A] This is an urgent project ** but it's stuck since we don't have any NEXT actions yet. ** However we do have: *** SOMEDAY some ideas about what might need doing later on *** MAYBE here's another idea we're not sure about yet * SOMEDAY This is an unimportant project ** Our NEXT actions are still SOMEDAY/MAYBE actions ** so is it stuck or not? ** Technically yes, but do we care? since the whole project is only a SOMEDAY. *** SOMEDAY when the project comes alive, this becomes a NEXT *** MAYBE here's another idea we're not sure about yet In the "someday" project above, notice how the distinction between the unimportant project and its as yet unimportant subtasks is blurred. That makes for inaccurate search results. How would we configure `org-agenda-stuck-projects' to get the desired results? Now compare with: * PROJECT [#A] This is an urgent project ** but it's stuck since we don't have any NEXT actions yet ** of priority #C or higher. ** However we do have: *** NEXT [#D] some ideas about what might need doing later on *** NEXT [#E] here's another idea we're not sure about yet * PROJECT [#D] This is an unimportant "someday" project *** SOMEDAY when the project comes alive, this "someday" action becomes a NEXT *** NEXT [#D] or we could mark it like this *** NEXT or even this, which would appear in searches for unprioritised items *** NEXT [#E] here's another "maybe" idea we're not sure about yet I don't really know what's best, but hopefully this is all food for thought. Happy New Year to all! Adam ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
Re: [Orgmode] SOMEDAY/MAYBE vs. low priorities
Pete Phillips ([EMAIL PROTECTED]) wrote: > > "Adam" == Adam Spiers <[EMAIL PROTECTED]> 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. Thanks a lot for the feedback. I have read the book several times but it was great to be reminded of his views on priorities. Having said that, I think I would really struggle to review on a regularly basis without some kind of prioritisation, since at the time of writing I have 324 NEXT actions and 82 PROJECTs. Surely that's way too many to review all of them within the reasonable timeframe of a weekly review (which I imagine would be 30-120 minutes)? Likewise, with this amount of "stuff" to deal with, I think I would struggle by using his 4-critera (context/time/energy available/priority) and 6-level (ground to 50,000ft) models alone for deciding what to do next - and that's even with having all the org-agenda-custom-commands already in place for viewing tasks by context,
Re: [Orgmode] SOMEDAY/MAYBE vs. low priorities
> "Adam" == Adam Spiers <[EMAIL PROTECTED]> 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
Re: [Orgmode] SOMEDAY/MAYBE vs. low priorities
On Dec 30, 2007 12:11 PM, Adam Spiers <[EMAIL PROTECTED]> wrote: > Pros: > > - Priorities become truly orthogonal to workflow, e.g. if your > workflow keywords are PROJECT, PROJDONE, NEXT, STARTED, WAITING, > DONE etc. then you can mark any of these as someday/maybe > priority. This is quite a big advantage AFAICS. > > Cons: > > - By default org agenda TODO searches will operate on all TODO > entries, regardless of priority. This means that you'd have to > customise every existing agenda view of TODOs to restrict to only > priorities #A to #C, which would be very cumbersome. > > What do people think? Are there other pros/cons, and is there a clean > solution to "generally" restricting TODO views to #C or higher > priority? The con would be less of an issue if there were a more generalized why to exclude things from agenda. Kinda how you don't have to tell agenda not to show you 'done' items or items tagged ARCHIVE. You could add your someday priority. I would consider it a general filter that takes items out of agenda view unless explicitly overridden in a query. It would probably introduce a bunch of other issues though. Edd ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] SOMEDAY/MAYBE vs. low priorities
GTD methodology suggests having "someday" and "maybe" task buckets for things which you want to remember to do at some undetermined point in the future. So far I have implemented this in org-mode by using SOMEDAY and MAYBE keywords. However I have been deliberating whether in fact these states are simply low priorities in disguise, and whether as a result it would make more sense to use [#D] for "someday" and [#E] for "maybe", on the grounds that "someday" implies that you really do want to accomplish the task eventually, whereas "maybe" implies that you're not yet decided whether you care too much if it ever gets accomplished, and is hence lower priority than "someday" (and probably the lowest priority imaginable, in fact). Pros: - Priorities become truly orthogonal to workflow, e.g. if your workflow keywords are PROJECT, PROJDONE, NEXT, STARTED, WAITING, DONE etc. then you can mark any of these as someday/maybe priority. This is quite a big advantage AFAICS. Cons: - By default org agenda TODO searches will operate on all TODO entries, regardless of priority. This means that you'd have to customise every existing agenda view of TODOs to restrict to only priorities #A to #C, which would be very cumbersome. What do people think? Are there other pros/cons, and is there a clean solution to "generally" restricting TODO views to #C or higher priority? ___ Emacs-orgmode mailing list Remember: use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
