emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed

From: Bernt Hansen <bernt@norang.ca>
To: Viktor Rosenfeld <listuser36@googlemail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: What do you use to identify projects (in the GTD sense)
Date: Mon, 12 Dec 2011 14:58:09 -0500	[thread overview]
Message-ID: <87obvdlfzi.fsf@norang.ca> (raw)
In-Reply-To: <20111212182955.GB46849@kenny.fritz.box> (Viktor Rosenfeld's message of "Mon, 12 Dec 2011 19:29:55 +0100")

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

next prev parent reply	other threads:[~2011-12-12 19:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2011-12-15 14:41         ` Defining dependencies (was: What do you use to identify projects (in the GTD sense)) Karl Voit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87obvdlfzi.fsf@norang.ca \
    --to=bernt@norang.ca \
    --cc=emacs-orgmode@gnu.org \
    --cc=listuser36@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).