* What do you use to identify projects (in the GTD sense)
@ 2011-10-10 6:21 Marcelo de Moraes Serpa
2011-10-10 11:30 ` Daniel Bausch
2011-10-11 1:28 ` Bernt Hansen
0 siblings, 2 replies; 11+ messages in thread
From: Marcelo de Moraes Serpa @ 2011-10-10 6:21 UTC (permalink / raw)
To: Org Mode
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
Hey list,
I'm wondering if you make the distinction between projects and actionable
items. If you stop to think about it (specially if you read GTD by David
Allen), you see that you can't really "do" a project, but only actions
related to it. It's a powerful and underestimated concept. Of course, a todo
list is still a reminder of things, and any list can be useful, but the more
specific you are, the less you have to think (process) and the more you can
actually execute.
Anyway, I was wondering how you guys differentiate between projects and next
actions (todo's) in your org lists. I myself use a :project: tag for
projects and todos have todo keywords before them. Projects never have a
todo keyword, except when DONE. I used to use a PROJECT keyword before, but
I felt that a tag seems to work better (and allows you to actually filter
todos without mixing projects). So, a typical list looks like this:
* New feature :project:
** TODO Create a mockup for the index page
** TODO Convert the mockup to html
* Renew passport :project:
** DONE Call for appointment
** TODO Interveiw
SCHEDULED <...>
** DONE Buy groceries :project: ...
How do you do it?
Thanks in advance,
- Marcelo.
[-- Attachment #2: Type: text/html, Size: 1454 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What do you use to identify projects (in the GTD sense)
2011-10-10 6:21 What do you use to identify projects (in the GTD sense) Marcelo de Moraes Serpa
@ 2011-10-10 11:30 ` Daniel Bausch
2011-10-10 18:44 ` Marcelo de Moraes Serpa
2011-10-11 1:28 ` Bernt Hansen
1 sibling, 1 reply; 11+ messages in thread
From: Daniel Bausch @ 2011-10-10 11:30 UTC (permalink / raw)
To: emacs-orgmode
Hello,
I use a todo keyword "PROJ" and a custom block agenda, that filters different
interesting groups for review.
(setq org-agenda-custom-commands
'(("g" "My GTD Agenda"
((agenda "" ((org-agenda-ndays 1)
(org-agenda-start-on-weekday nil)
(org-agenda-entry-types '(:timestamp :sexp))
(org-agenda-overriding-header "Appointments")))
(agenda "" ((org-agenda-ndays 1)
(org-agenda-start-on-weekday nil)
(org-agenda-entry-types '(:deadline))
(org-agenda-overriding-header "Upcoming Deadlines")
(org-agenda-sorting-strategy '(priority-down time-down))
(org-agenda-skip-function '(org-agenda-skip-entry-if 'todo
'done))))
(agenda "" ((org-agenda-ndays 1)
(org-agenda-start-on-weekday nil)
(org-agenda-entry-types '(:scheduled))
(org-agenda-overriding-header "Scheduled")
(org-agenda-sorting-strategy '(priority-down time-down))
(org-agenda-skip-function '(org-agenda-skip-entry-if 'todo
'done))))
(todo "WAIT" ((org-agenda-sorting-strategy '(priority-down))
(org-agenda-overriding-header "Waiting For")))
(todo "NEXT" ((org-agenda-sorting-strategy '(priority-down effort-
down))
(org-agenda-skip-function '(org-agenda-skip-entry-if
'scheduled 'deadline))
(org-agenda-overriding-header "Next actions not being
scheduled nor having a deadline")))
(todo "TODO" ((org-agenda-sorting-strategy '(priority-down effort-
down))
(org-agenda-skip-function '(org-agenda-skip-entry-if
'scheduled 'deadline))
(org-agenda-overriding-header "Future actions not
being scheduled nor having a deadline")))
(todo "PROJ" ((org-agenda-overriding-header "Active Projects")))))))
Along with colors
'(org-todo-keyword-faces (quote (("PROJ" :foreground "Orange" :weight bold)
("MSTN" :foreground "VioletRed" :weight bold) ("WAIT" :foreground "Blue"
:weight bold) ("CNCL" :foreground "MediumSeaGreen" :weight bold))))
and
'(org-enforce-todo-checkbox-dependencies t)
'(org-enforce-todo-dependencies t)
this works really well for GTD.
Kind regards,
Daniel
Am Montag 10 Oktober 2011, 08:21:57 schrieb Marcelo de Moraes Serpa:
> Hey list,
>
> I'm wondering if you make the distinction between projects and actionable
> items. If you stop to think about it (specially if you read GTD by David
> Allen), you see that you can't really "do" a project, but only actions
> related to it. It's a powerful and underestimated concept. Of course, a
> todo list is still a reminder of things, and any list can be useful, but
> the more specific you are, the less you have to think (process) and the
> more you can actually execute.
>
> Anyway, I was wondering how you guys differentiate between projects and
> next actions (todo's) in your org lists. I myself use a :project: tag for
> projects and todos have todo keywords before them. Projects never have a
> todo keyword, except when DONE. I used to use a PROJECT keyword before,
> but I felt that a tag seems to work better (and allows you to actually
> filter todos without mixing projects). So, a typical list looks like this:
>
> * New feature :project:
> ** TODO Create a mockup for the index page
> ** TODO Convert the mockup to html
> * Renew passport :project:
> ** DONE Call for appointment
> ** TODO Interveiw
> SCHEDULED <...>
> ** DONE Buy groceries :project: ...
>
> How do you do it?
>
> Thanks in advance,
>
> - Marcelo.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What do you use to identify projects (in the GTD sense)
2011-10-10 11:30 ` Daniel Bausch
@ 2011-10-10 18:44 ` Marcelo de Moraes Serpa
2011-10-11 6:20 ` Daniel Bausch
0 siblings, 1 reply; 11+ messages in thread
From: Marcelo de Moraes Serpa @ 2011-10-10 18:44 UTC (permalink / raw)
To: Daniel Bausch; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 4096 bytes --]
Hi Daneil,
Looks interesting. Could you share a sample tree with projects and actions?
Cheers,
- Marcelo.
On Mon, Oct 10, 2011 at 6:30 AM, Daniel Bausch <DanielBausch@gmx.de> wrote:
> Hello,
>
> I use a todo keyword "PROJ" and a custom block agenda, that filters
> different
> interesting groups for review.
>
> (setq org-agenda-custom-commands
> '(("g" "My GTD Agenda"
> ((agenda "" ((org-agenda-ndays 1)
> (org-agenda-start-on-weekday nil)
> (org-agenda-entry-types '(:timestamp :sexp))
> (org-agenda-overriding-header "Appointments")))
> (agenda "" ((org-agenda-ndays 1)
> (org-agenda-start-on-weekday nil)
> (org-agenda-entry-types '(:deadline))
> (org-agenda-overriding-header "Upcoming Deadlines")
> (org-agenda-sorting-strategy '(priority-down
> time-down))
> (org-agenda-skip-function '(org-agenda-skip-entry-if
> 'todo
> 'done))))
> (agenda "" ((org-agenda-ndays 1)
> (org-agenda-start-on-weekday nil)
> (org-agenda-entry-types '(:scheduled))
> (org-agenda-overriding-header "Scheduled")
> (org-agenda-sorting-strategy '(priority-down
> time-down))
> (org-agenda-skip-function '(org-agenda-skip-entry-if
> 'todo
> 'done))))
> (todo "WAIT" ((org-agenda-sorting-strategy '(priority-down))
> (org-agenda-overriding-header "Waiting For")))
> (todo "NEXT" ((org-agenda-sorting-strategy '(priority-down effort-
> down))
> (org-agenda-skip-function '(org-agenda-skip-entry-if
> 'scheduled 'deadline))
> (org-agenda-overriding-header "Next actions not
> being
> scheduled nor having a deadline")))
> (todo "TODO" ((org-agenda-sorting-strategy '(priority-down effort-
> down))
> (org-agenda-skip-function '(org-agenda-skip-entry-if
> 'scheduled 'deadline))
> (org-agenda-overriding-header "Future actions not
> being scheduled nor having a deadline")))
> (todo "PROJ" ((org-agenda-overriding-header "Active
> Projects")))))))
>
>
> Along with colors
>
> '(org-todo-keyword-faces (quote (("PROJ" :foreground "Orange" :weight
> bold)
> ("MSTN" :foreground "VioletRed" :weight bold) ("WAIT" :foreground "Blue"
> :weight bold) ("CNCL" :foreground "MediumSeaGreen" :weight bold))))
>
> and
>
> '(org-enforce-todo-checkbox-dependencies t)
> '(org-enforce-todo-dependencies t)
>
> this works really well for GTD.
>
> Kind regards,
> Daniel
>
> Am Montag 10 Oktober 2011, 08:21:57 schrieb Marcelo de Moraes Serpa:
> > Hey list,
> >
> > I'm wondering if you make the distinction between projects and actionable
> > items. If you stop to think about it (specially if you read GTD by David
> > Allen), you see that you can't really "do" a project, but only actions
> > related to it. It's a powerful and underestimated concept. Of course, a
> > todo list is still a reminder of things, and any list can be useful, but
> > the more specific you are, the less you have to think (process) and the
> > more you can actually execute.
> >
> > Anyway, I was wondering how you guys differentiate between projects and
> > next actions (todo's) in your org lists. I myself use a :project: tag for
> > projects and todos have todo keywords before them. Projects never have a
> > todo keyword, except when DONE. I used to use a PROJECT keyword before,
> > but I felt that a tag seems to work better (and allows you to actually
> > filter todos without mixing projects). So, a typical list looks like
> this:
> >
> > * New feature :project:
> > ** TODO Create a mockup for the index page
> > ** TODO Convert the mockup to html
> > * Renew passport :project:
> > ** DONE Call for appointment
> > ** TODO Interveiw
> > SCHEDULED <...>
> > ** DONE Buy groceries :project: ...
> >
> > How do you do it?
> >
> > Thanks in advance,
> >
> > - Marcelo.
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 5214 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What do you use to identify projects (in the GTD sense)
2011-10-10 18:44 ` Marcelo de Moraes Serpa
@ 2011-10-11 6:20 ` Daniel Bausch
0 siblings, 0 replies; 11+ messages in thread
From: Daniel Bausch @ 2011-10-11 6:20 UTC (permalink / raw)
To: Marcelo de Moraes Serpa; +Cc: emacs-orgmode
Hi Marcelo,
its nothing special:
* Working Area (the order of these models some kind of global priorization)
:PROPERTIES:
:CATEGORY: CAT-A (<- some identifier to be displayed on the left of agenda)
:END:
** PROJ outcome or project title
*** DONE something done
*** NEXT the next action
*** TODO something currently not actionable (because of dependencies or so)
**** PROJ some subproject
***** ... you get it
Often I prefix the individual action items with short identifiers for the
containing project to give me some context in the agenda. Instead of
extending the strings it helps to keep them shorter.
For example:
TODO software-x: talk to Fred about the missing requirements
instead of
TODO talk to Fred about the missing requirements of software-x
In english its not very efficient, but in German it can save you a lot of
letters and you have a fixed position to look for the context. A tag may fit
the same needs but they are located less prominently and I think one needs the
context first.
Daniel
Am Montag 10 Oktober 2011, 20:44:46 schrieb Marcelo de Moraes Serpa:
> Hi Daneil,
>
> Looks interesting. Could you share a sample tree with projects and actions?
>
> Cheers,
>
> - Marcelo.
>
> On Mon, Oct 10, 2011 at 6:30 AM, Daniel Bausch <DanielBausch@gmx.de> wrote:
> > Hello,
> >
> > I use a todo keyword "PROJ" and a custom block agenda, that filters
> > different
> > interesting groups for review.
> >
> > (setq org-agenda-custom-commands
> >
> > '(("g" "My GTD Agenda"
> >
> > ((agenda "" ((org-agenda-ndays 1)
> >
> > (org-agenda-start-on-weekday nil)
> > (org-agenda-entry-types '(:timestamp :sexp))
> > (org-agenda-overriding-header "Appointments")))
> >
> > (agenda "" ((org-agenda-ndays 1)
> >
> > (org-agenda-start-on-weekday nil)
> > (org-agenda-entry-types '(:deadline))
> > (org-agenda-overriding-header "Upcoming Deadlines")
> > (org-agenda-sorting-strategy '(priority-down
> >
> > time-down))
> >
> > (org-agenda-skip-function '(org-agenda-skip-entry-if
> >
> > 'todo
> > 'done))))
> >
> > (agenda "" ((org-agenda-ndays 1)
> >
> > (org-agenda-start-on-weekday nil)
> > (org-agenda-entry-types '(:scheduled))
> > (org-agenda-overriding-header "Scheduled")
> > (org-agenda-sorting-strategy '(priority-down
> >
> > time-down))
> >
> > (org-agenda-skip-function '(org-agenda-skip-entry-if
> >
> > 'todo
> > 'done))))
> >
> > (todo "WAIT" ((org-agenda-sorting-strategy '(priority-down))
> >
> > (org-agenda-overriding-header "Waiting For")))
> >
> > (todo "NEXT" ((org-agenda-sorting-strategy '(priority-down
> > effort-
> >
> > down))
> >
> > (org-agenda-skip-function
> > '(org-agenda-skip-entry-if
> >
> > 'scheduled 'deadline))
> >
> > (org-agenda-overriding-header "Next actions not
> >
> > being
> > scheduled nor having a deadline")))
> >
> > (todo "TODO" ((org-agenda-sorting-strategy '(priority-down
> > effort-
> >
> > down))
> >
> > (org-agenda-skip-function
> > '(org-agenda-skip-entry-if
> >
> > 'scheduled 'deadline))
> >
> > (org-agenda-overriding-header "Future actions not
> >
> > being scheduled nor having a deadline")))
> >
> > (todo "PROJ" ((org-agenda-overriding-header "Active
> >
> > Projects")))))))
> >
> >
> > Along with colors
> >
> > '(org-todo-keyword-faces (quote (("PROJ" :foreground "Orange" :weight
> >
> > bold)
> > ("MSTN" :foreground "VioletRed" :weight bold) ("WAIT" :foreground "Blue"
> >
> > :weight bold) ("CNCL" :foreground "MediumSeaGreen" :weight bold))))
> >
> > and
> >
> > '(org-enforce-todo-checkbox-dependencies t)
> > '(org-enforce-todo-dependencies t)
> >
> > this works really well for GTD.
> >
> > Kind regards,
> > Daniel
> >
> > Am Montag 10 Oktober 2011, 08:21:57 schrieb Marcelo de Moraes Serpa:
> > > Hey list,
> > >
> > > I'm wondering if you make the distinction between projects and
> > > actionable items. If you stop to think about it (specially if you read
> > > GTD by David Allen), you see that you can't really "do" a project, but
> > > only actions related to it. It's a powerful and underestimated
> > > concept. Of course, a todo list is still a reminder of things, and any
> > > list can be useful, but the more specific you are, the less you have
> > > to think (process) and the more you can actually execute.
> > >
> > > Anyway, I was wondering how you guys differentiate between projects and
> > > next actions (todo's) in your org lists. I myself use a :project: tag
> > > for projects and todos have todo keywords before them. Projects never
> > > have a todo keyword, except when DONE. I used to use a PROJECT keyword
> > > before, but I felt that a tag seems to work better (and allows you to
> > > actually filter todos without mixing projects). So, a typical list
> > > looks like
> >
> > this:
> > > * New feature :project:
> > > ** TODO Create a mockup for the index page
> > > ** TODO Convert the mockup to html
> > > * Renew passport :project:
> > > ** DONE Call for appointment
> > > ** TODO Interveiw
> > >
> > > SCHEDULED <...>
> > >
> > > ** DONE Buy groceries :project: ...
> > >
> > > How do you do it?
> > >
> > > Thanks in advance,
> > >
> > > - Marcelo.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What do you use to identify projects (in the GTD sense)
2011-10-10 6:21 What do you use to identify projects (in the GTD sense) Marcelo de Moraes Serpa
2011-10-10 11:30 ` Daniel Bausch
@ 2011-10-11 1:28 ` Bernt Hansen
2011-10-11 8:16 ` Sven Bretfeld
2011-12-11 16:49 ` Viktor Rosenfeld
1 sibling, 2 replies; 11+ messages in thread
From: Bernt Hansen @ 2011-10-11 1:28 UTC (permalink / raw)
To: Marcelo de Moraes Serpa; +Cc: Org Mode
Marcelo de Moraes Serpa <celoserpa@gmail.com> writes:
> I'm wondering if you make the distinction between projects and
> actionable items.
> How do you do it?
http://doc.norang.ca/org-mode.html#Projects
-Bernt
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What do you use to identify projects (in the GTD sense)
2011-10-11 1:28 ` Bernt Hansen
@ 2011-10-11 8:16 ` Sven Bretfeld
2011-12-11 16:49 ` Viktor Rosenfeld
1 sibling, 0 replies; 11+ messages in thread
From: Sven Bretfeld @ 2011-10-11 8:16 UTC (permalink / raw)
To: Bernt Hansen; +Cc: Org Mode, Marcelo de Moraes Serpa
Hi Bernt
Bernt Hansen <bernt@norang.ca> writes:
> http://doc.norang.ca/org-mode.html#Projects
Wow, that is a WONDERFUL page you shared with us. Thank you very much!
It will cost me hours go through it and see what I can implement for my
setup. Can't you think about others' time before posting such great
stuff?
Here is my setup and workflow:
I'm quite an orthodox GTD user with one exception: I blended two
concepts of ZTD (Zen to Done
http://zenhabits.net/zen-to-done-ztd-the-ultimate-simple-productivity-system/)
which is a mix of GTD and other systems. What I took from it is the two
tags :MIT: (Most important thing of the day) and :BIGROCK: (Most
important project of the week). Usually MITs are Next Steps which I do
as early as possible during the day, normally there are two or three of
them each day. Bigrocks are privileged projects which I return to most
often, I usually have one or two of them per week.
I use one main org-file. Spheres of responsibility are top level
headings containing neither tags nor todo-keywords:
,----
| * Termine (contains only appointments)
| * Teaching
| * Institute
| * Research Department
| * Research Consortium
| * Personal Research
| * Readings
| * Home Projects
| * Friends
| * Someday/Maybe
| * Stuff to remember (here for example birthdays are defined)
`----
The second level contains projects which are tagged with :PROJECT:. The
third level are associated next steps containing a resource tag.
,----
| * Institute
| ** Major Book Order :PROJECT:
| *** DONE Advertise a position for a coordinator :OFFICE:
| *** WAITING Wait for applications :OFFICE:
| *** Choose an appropriate person :OFFICE:
| *** Call a meeting :OFFICE:
| *** Set up delegation project for supervision :OFFICE:
`----
As you see, only the first two steps contain a todo-keyword. This is
because the second step is running at the moment and cannot choose a
person before the position was actually advertised and the application
deadline has come. I use triggers to set the next step to the
appropriate state when the previous step is marked DONE:
,----
| *** WAITING Wait for applications :OFFICE:
| :PROPERTIES:
| :TRIGGER: chain-siblings(NEXT)
| :END:
| *** Choose an appropriate person :OFFICE:
`----
So, after the application deadline has come, I mark the WAITING entry
DONE and the next entry is automatically set to NEXT. After this is
DONE, "Call a meeting" will be set to NEXT.
,----
| *** DONE Wait for applications :OFFICE:
| *** NEXT Choose an appropriate person :OFFICE:
| :PROPERTIES:
| :TRIGGER: chain-siblings(NEXT)
| :END:
| *** Call a meeting :OFFICE:
`----
In this way my agenda view for "NEXT actions at OFFICE" contains only
actions which can actually be done immediately.
I use to revise my project lists on a daily base. This is the first
thing I do in the morning. It takes about 15 minutes. This is not
orthodox GTD behavior but only this way a can make my mind free and be
sure that I don't forget deadlines and don't neglect projects. I have a
special entry for this revision that appears on top of my
day-agenda-view:
,----
| Dienstag 11 Oktober 2011
| 8:00...... ----------------
| 9:23...... now - - - - - - - - - - - -
| 10:00...... ----------------
| 12:00...... ----------------
| diary: 14:00-15:00 Meeting with Mrs. Smith
| 14:00...... ----------------
| 16:00...... ----------------
| Termine:18:00-20:00 Central Asia group meeting :MEETING:
| 20:00...... ----------------
| DailyTasks: Scheduled: REGULAR Daily Review [0/7]
| HomeProjects: Scheduled: REGULAR Water flowers :HOME:
`----
I have a special keyword for regular tasks because I don't like them to
appear in NEXT lists. These regular tasks always have a schedule and
therefore appear only in the day-agenda:
,----
| ** REGULAR Daily Review [0/7]
| SCHEDULED: <2011-10-10 Mo .+1d>
| :PROPERTIES:
| :REPEAT_TO_STATE: REGULAR
| :END:
| - [ ] review daily agenda
| - [ ] review Waiting
| - [ ] review Delegated
| - [ ] review Projects
| - [ ] review Stuck Projects
| - [ ] review Bigrocks
| - [ ] make new MITs from
| - [ ] OFFICE
| - [ ] HOME
| - [ ] SCHRIESHEIM
| - [ ] PHONE
| - [ ] READING
`----
For distant projects I have the Someday/Maybe category:
,----
| ** Send documents to tax adviser
| NOT_STARTED
| *** Start Project
| SCHEDULED: <2012-01-02 Mo>
| *** Gather documents :HOME:
| :PROPERTIES:
| :TRIGGER: chain-siblings(NEXT)
| :END:
| *** Copy documents :OFFICE:
| *** Prepare letter :HOME:
| *** Send letter :SHOPPING:
`----
These future projects contain the keyword NOT_STARTED to prevent them
from appearing in the projects list. Starting the project is a scheduled
action. When it appears in my day agenda, I refile to project to the
appropriate responsibility category (in this case "Home Projects"), give
it the PROJECT tag and set the first action to NEXT.
The MEETING tag you can see in the daily-agenda view above, has only one
function: It is converted to the string [mute] when I do an iCal export
which I feed into GoogleCalendar every week (yes, I do have a "weekly"
review also). This serves as a keyphrase used to mute my Android phone
automatically during meetings (using the App Tasker).
This is the main idea of my setup. It contains some other stuff not
mentioned above. For example a special file for things captured en route
with the phone (MobileOrg), and a first level header "New Tasks" where
org-capture material is stored. My wife has writing access to another
file shared via Dropbox to inform me about things to do when we are not
at home together (I had to give her an Emacs crash course for that). I
use to share appointments with GoogleCalendar and use the procedure
described on this list several times to synchronize appointments between
both.
Take what you find useful. Any hints for improvement are very welcome.
Greetings,
Sven
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What do you use to identify projects (in the GTD sense)
2011-10-11 1:28 ` Bernt Hansen
2011-10-11 8:16 ` Sven Bretfeld
@ 2011-12-11 16:49 ` Viktor Rosenfeld
2011-12-11 22:18 ` Bernt Hansen
1 sibling, 1 reply; 11+ messages in thread
From: Viktor Rosenfeld @ 2011-12-11 16:49 UTC (permalink / raw)
To: emacs-orgmode
I use Bernt's approach with a few modifications. Basically I don't use
subprojects. I think Bernt's handling of subprojects is broken, because
a NEXT keyword burried in a subproject keeps the entire project off the
stuck projects lists. (Please correct me if I'm wrong.)
My solution is to move a project's task that itself requires subtasks
out of the project and make it a top-level project in itself.
This makes archiving somewhat cumbersome, as (sub) projects may get
archived out of order. But for me archiving is a very manual process
anyway. I delete lots of done projects or move the information to a
notes file.
I also have a lot of simple tasks that aren't really part of project.
(Like "watch my sister's kids". What project would I put that under?)
These one-shot tasks appear on my next action agenda block along with
project next action. They do not appear in the "Stuck projects" agenda
block if they dont' have a NEXT keyword, but in a a seperate agenda
block, because there is no need to determine the next action. I just
have to determine the work context or maybe schedule them for a
particular day.
Bernt Hansen wrote:
> Marcelo de Moraes Serpa <celoserpa@gmail.com> writes:
>
> > I'm wondering if you make the distinction between projects and
> > actionable items.
>
> > How do you do it?
>
> http://doc.norang.ca/org-mode.html#Projects
>
> -Bernt
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What do you use to identify projects (in the GTD sense)
2011-12-11 16:49 ` Viktor Rosenfeld
@ 2011-12-11 22:18 ` Bernt Hansen
2011-12-12 18:29 ` Viktor Rosenfeld
0 siblings, 1 reply; 11+ messages in thread
From: Bernt Hansen @ 2011-12-11 22:18 UTC (permalink / raw)
To: Viktor Rosenfeld; +Cc: emacs-orgmode
Viktor Rosenfeld <listuser36@googlemail.com> writes:
> I use Bernt's approach with a few modifications. Basically I don't use
> subprojects. I think Bernt's handling of subprojects is broken, because
> a NEXT keyword burried in a subproject keeps the entire project off the
> stuck projects lists. (Please correct me if I'm wrong.)
It's possible it's broken :) but subprojects are considered separately
for the stuck project list. It is true that if any subproject has a
NEXT task then the overall project is not stuck (but doesn't that makes
sense?)
* TODO Project
** TODO SubProject A
*** NEXT Task One
** TODO SubProject B
*** TODO Task Two
In the above layout Project is not stuck (it has Task One as a NEXT
task) but SubProject B is stuck (it has no next task and shows up on the
stuck project list)
Also as soon as Task One is DONE than both SubProject A and Project are
both stuck until a new NEXT task is identified (or they are in turn
marked DONE)
Regards,
Bernt
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What do you use to identify projects (in the GTD sense)
2011-12-11 22:18 ` Bernt Hansen
@ 2011-12-12 18:29 ` Viktor Rosenfeld
2011-12-12 19:58 ` Bernt Hansen
2011-12-15 14:41 ` Defining dependencies (was: What do you use to identify projects (in the GTD sense)) Karl Voit
0 siblings, 2 replies; 11+ messages in thread
From: Viktor Rosenfeld @ 2011-12-12 18:29 UTC (permalink / raw)
To: Bernt Hansen; +Cc: emacs-orgmode
Hi Bernt,
sorry, I wasn't more specific. My problem is with projects that consist
of subprojects and simple tasks. Consider the following scenario:
* TODO Project
** TODO Subproject A
*** NEXT Task A1
*** TODO Task A2
** NEXT Task B
** TODO Task C
** TODO ...
Task B and C have to be done in order. However, Subproject A is somewhat
independent and can be done in parallel, while working on Task B and C.
When I mark Task B as DONE, the Project is still unstuck because of the
a NEXT task in Subproject A. Meaning that I never get to schedule Task C
or any following tasks until I'm done with Subproject A.
One solution to this problem would be to trigger a state change in Task
C automatically when Task B is done. But I'm afraid that is too much
setup and also not flexible enough. Often, when I consider a stuck
project I schedule next actions that I haven't thought of before or even
put the project on a someday list.
Another solution would be to implement a stale projects list, i.e. a
list of projects that have defined next actions, but haven't seen any
work in the last X days.
Cheers,
Viktor
PS: Your org-mode site is generally the bomb!
Bernt Hansen wrote:
> Viktor Rosenfeld <listuser36@googlemail.com> writes:
>
> > I use Bernt's approach with a few modifications. Basically I don't use
> > subprojects. I think Bernt's handling of subprojects is broken, because
> > a NEXT keyword burried in a subproject keeps the entire project off the
> > stuck projects lists. (Please correct me if I'm wrong.)
>
> It's possible it's broken :) but subprojects are considered separately
> for the stuck project list. It is true that if any subproject has a
> NEXT task then the overall project is not stuck (but doesn't that makes
> sense?)
>
> * TODO Project
> ** TODO SubProject A
> *** NEXT Task One
> ** TODO SubProject B
> *** TODO Task Two
>
> In the above layout Project is not stuck (it has Task One as a NEXT
> task) but SubProject B is stuck (it has no next task and shows up on the
> stuck project list)
>
> Also as soon as Task One is DONE than both SubProject A and Project are
> both stuck until a new NEXT task is identified (or they are in turn
> marked DONE)
>
> Regards,
> Bernt
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: What do you use to identify projects (in the GTD sense)
2011-12-12 18:29 ` Viktor Rosenfeld
@ 2011-12-12 19:58 ` Bernt Hansen
2011-12-15 14:41 ` Defining dependencies (was: What do you use to identify projects (in the GTD sense)) Karl Voit
1 sibling, 0 replies; 11+ messages in thread
From: Bernt Hansen @ 2011-12-12 19:58 UTC (permalink / raw)
To: Viktor Rosenfeld; +Cc: emacs-orgmode
Viktor Rosenfeld <listuser36@googlemail.com> writes:
> Hi Bernt,
>
> sorry, I wasn't more specific. My problem is with projects that consist
> of subprojects and simple tasks. Consider the following scenario:
>
> * TODO Project
> ** TODO Subproject A
> *** NEXT Task A1
> *** TODO Task A2
> ** NEXT Task B
> ** TODO Task C
> ** TODO ...
>
> Task B and C have to be done in order. However, Subproject A is somewhat
> independent and can be done in parallel, while working on Task B and C.
>
> When I mark Task B as DONE, the Project is still unstuck because of the
> a NEXT task in Subproject A. Meaning that I never get to schedule Task C
> or any following tasks until I'm done with Subproject A.
>
> One solution to this problem would be to trigger a state change in Task
> C automatically when Task B is done. But I'm afraid that is too much
> setup and also not flexible enough. Often, when I consider a stuck
> project I schedule next actions that I haven't thought of before or even
> put the project on a someday list.
>
> Another solution would be to implement a stale projects list, i.e. a
> list of projects that have defined next actions, but haven't seen any
> work in the last X days.
Okay - I have a custom skip function for identifying stuck projects.
You should be able to create one that only looks at immediate subtasks
to address the above example. This would make project independent of
subprojects when determining if it is stuck or not without requiring you
to rearrange your task hierarchy.
>
> Cheers,
> Viktor
>
> PS: Your org-mode site is generally the bomb!
Thanks :)
HTH,
Bernt
^ permalink raw reply [flat|nested] 11+ messages in thread
* Defining dependencies (was: What do you use to identify projects (in the GTD sense))
2011-12-12 18:29 ` Viktor Rosenfeld
2011-12-12 19:58 ` Bernt Hansen
@ 2011-12-15 14:41 ` Karl Voit
1 sibling, 0 replies; 11+ messages in thread
From: Karl Voit @ 2011-12-15 14:41 UTC (permalink / raw)
To: emacs-orgmode
* Viktor Rosenfeld <listuser36@googlemail.com> wrote:
>
> * TODO Project
> ** TODO Subproject A
> *** NEXT Task A1
> *** TODO Task A2
> ** NEXT Task B
> ** TODO Task C
> ** TODO ...
>
> Task B and C have to be done in order. However, Subproject A is somewhat
> independent and can be done in parallel, while working on Task B and C.
>
> When I mark Task B as DONE, the Project is still unstuck because of the
> a NEXT task in Subproject A. Meaning that I never get to schedule Task C
> or any following tasks until I'm done with Subproject A.
>
> One solution to this problem would be to trigger a state change in Task
> C automatically when Task B is done. But I'm afraid that is too much
> setup and also not flexible enough.
I had no trouble to set up this using the examples from
http://doc.norang.ca/org-mode.html and
http://orgmode.org/worg/org-contrib/org-depend.html
With org-depend you can also use another method to overcome this
problem:
** NEXT Task B
[...]
:ID: mytaskB
[...]
** NEXT Task C
[...]
:BLOCKER: mytaskB
[...]
I am not using stuck project information (yet) but this does not
show Task C on my agenda at least. Which is quite nice since it is
way more flexible and can be used in a broader way.
--
Karl Voit
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-12-15 14:41 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-10 6:21 What do you use to identify projects (in the GTD sense) Marcelo de Moraes Serpa
2011-10-10 11:30 ` Daniel Bausch
2011-10-10 18:44 ` Marcelo de Moraes Serpa
2011-10-11 6:20 ` Daniel Bausch
2011-10-11 1:28 ` Bernt Hansen
2011-10-11 8:16 ` Sven Bretfeld
2011-12-11 16:49 ` Viktor Rosenfeld
2011-12-11 22:18 ` Bernt Hansen
2011-12-12 18:29 ` Viktor Rosenfeld
2011-12-12 19:58 ` Bernt Hansen
2011-12-15 14:41 ` Defining dependencies (was: What do you use to identify projects (in the GTD sense)) Karl Voit
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).