Re: depending TODOs, scheduling following TODOs automatically

[Adam Spiers <orgmode@adamspiers.org>]

On Mon, Oct 08, 2007 at 09:55:12PM +0100, Bastien wrote:
> Implementing tasks-dependencies sounds pretty exciting!

Yes, I've been wanting this too.

> I'd like to jump in this discussion with a very simple idea.
> 
> ,----
> | * TODO When this task is marked done, send SCHEDULED to the next task
> |   :PROPERTIES:
> |   :SEND: {SCHEDULED 'next "+1d"} {TODO 'next "TODO"}
> |   :END:
> | 
> | * When previous task done, this will turn TODO, SCHEDULED for +1 day
> `----
> 
> The basic idea is to *send* a property to a task depending on a state
> change - in the example above, depending on switching from TODO to DONE.
> 
> "SEND" would be a special property, composed of repeating curly braced
> constructs {PROP ADDR VAL}, each of one being composed of:
> 
>   PROP: the property to be sent
> 
>   ADDR: the relative or absolute "address" of the task
> 
>   VAL:  the new value for this property (default to the value this
>         property had in the previous task)
> 
> The "absolute" address could be a GUID or a human readable label. 
> 
> I think this way to send a property (or even to propagate multiple
> properties to multiple tasks, if needed) would spare us the fuss of
> implementing real dependencies with real links between the tasks.  
> 
> What do you think?

It could work.

I like the idea of making it more generic, as people could almost
certainly find new uses for expressing an arbitrary relationship
between two items based on their personalised workflows (a bit like
W3C's <link rel="...">), e.g.

  - if A changes to DONE, change B from BLOCKED to NEXT
    (this is the obvious one)

  - if A changes to DONE, change B from NEXT to CANCELLED
    (if only A or B needs to be done, not both)

There must be others people can think of easily.

Or you could even have a state change creating new items from
templates!  This could allow some really clever workflows where
arrival at one stage in the workflow triggers more than one new
action.

What exactly would the ADDR look like?

I think an ideal implementation should support bidirectional
navigation, i.e. jumping from a blocked task to its blocker, or in the
opposite direction.  And that begs the question: would you need
bidirectional updates too?  E.g. if B is WAITING on A, and A is
changed to DONE, then B gets updated to NEXT, but alternatively if B
is changed from WAITING to NEXT, should you update A to DONE?  I think
the answer in this particular (bad) example is no, because you might
realise that you can proceed with B even though A is still not DONE.
But there may be other examples where it makes sense.