Re: depending TODOs, scheduling following TODOs automatically

[Bastien <bzg@altern.org>]

Adam Spiers <orgmode@adamspiers.org> writes:

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

Updating my own proposal.

We could use the TODO keywords instead of "SEND" as a way to say that
reaching a particular todo state should trigger some kind of action.

See this for example[1]:

,----
| * TODO When this task is marked done, send SCHEDULED to the next task
|   :PROPERTIES:
|   :CANCELED>: {SCHEDULED 'subtree nil) {TODO 'subtree "CANCELED"}
|   :DONE>: {SCHEDULED 'next "+1d"} {TODO 'next "NEXT"}
|   :END:
`----

This would translate: 

- when the todo state CANCELED is reached, trigger these two actions: 
  + UNSCHEDULED all tasks in the current subtree (SCHEDULED to nil)
  + If a task in this subtree has a TODO keyword, turn it to CANCELED

- when the todo is set to DONE, trigger these two actions:
  + SCHEDULED next task (same level) for a day after current SCHEDULED
  + If the next task has a TODO keyword, turn it to NEXT

(I took the SCHEDULED and TODO properties, but this could be any
property from the :PROPERTIES: drawer.)

Therefore we would spare the cost of a new SEND special property. We
would just need to add TODO keywords to the set of special properties
(there is very little chance that users already use TODO keywords as
properties anyway, right?)

The drawback of using todo keywords instead of "SEND" is that SEND calls
for RECV, and having both SEND and RECV would make it possible to handle
dependencies in two directions: from the source to the target and back
to the source.

I first said this idea was "simple" because it just handle *onward*
propagation of properties.  The rationale behind this are: 1) I think
it's more natural and 2) I prefer backward dependencies to be as much 
as possible defined bye the structure of the file itself:

For example, see this simple workflow:

* Task A
  :PROPERTIES:
  :DONE>: {TODO 'next "NEXT" t}
  :END:
* Task B
* Task C
* Task D

We don't need to say in task "C" that it depends on task be. If we know
we're using a dependencies-aware setup in the current subtree, we know
this task will turned "NEXT" when required.

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

Ahem.  I must say all this is getting a bit crazy here.  But why not?

> What exactly would the ADDR look like?

As stated above, this should be thoughtfully designed.  I can think of
this set: 'next 'previous 'subtree 'next-subtree 'previous-subtree.  Or
maybe just {'next 'previous 'subtree} if we have a way to define scope
for these.

> 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?

* Task A
* Task B
  :PROPERTIES:
  :>NEXT: {TODO 'previous "DONE"}
  :END:
* Task C
* Task D

Remark ">" in ">NEXT". Task A is a blocker for Task B, which becomes
"NEXT" iff previous task is DONE.  This is equivalent to the example
above.  My point is that it shouldn't be necessary to define the two
directions of the dependence.  I guess one is enough for most cases.

> 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 guess most often we should'nt.  

The common case is that some achievement calls for new tasks (at least
this is what we can *predict* we planning). The fact that an achievement
may retro-act on something that it depended upon is not that crucial.
It's safe not to care about it too much. 

Putting it in one word: think *forward*!  

It's not as if we were handling packages dependencies.

Notes: 
[1]  Three notes on the proposed implementation:

1) the ">" after "CANCELED>" says this properties is a send property.
   It lets you make a distinction between this two actions:

   :TODO>: {TODO 'next TODO} 

     => when this headline is set to TODO, set the next headline todo
        state to TODO.  (Poo-poo-pee-doo!)

   :TODO>: {TODO> 'next "{NEXT 'next "MAYBE"}"}

     => when turned TODO, set the next headline "TODO>" property to
        {NEXT 'next "MAYBE"}.  People using action to trigger action
        that will set a new action definition for items surely miss
        something in life, but who doesn't?

2) the above sentences starting with "If a task ... if the next task"
   implicitely calls for fourth element in the {...} syntax:

   {PROP ADDR VAL FORCE}

   If FORCE, then set the property of the target task, even if this
   property is not already listed in the :PROPERTIES: drawer.

   It not FORCE, just set target's property if it already exists.

3) Depending on the set of authorized values for ADDR, we could also
   delimit the scope of the action more precisely:

   {PROP [ADDR SCOPE] VAL FORCE}

   SCOPE could be a numeric value, for example, if we want the action to
   affect the next ('next) `n' headlines or if want the action to affect
   the `n' next levels in the subtree ('subtree).

   But this requires to check carefully for consistency while trying to
   figure out what are the good candidates for ADDR and SCOPE.

-- 
Bastien