Re: depending TODOs, scheduling following TODOs automatically

[Carsten Dominik <dominik@science.uva.nl>]

Hi everyone,

I have read this discussion with great interest, and I would like to
add a few thoughts.

First, let me say that I was surprised that quite a few people are so
keen to see this kind of features.  I myself would worry
a lot about spending more time to set up and maintain these connections,
than I would be saving by using them.  And I am not sure if Org-mode
really scales up nicely when it comes to really large projects, large 
number
of people interacting, keeping complex GANTT charts up to date etc.
Me, I have sometimes made these charts during an initial project setup,
to get a feeling what amount of time and resources would be needed, but 
I have
never kept these complex structures alive and up to date.  Obviously, 
others
believe they can.

About implementing triggers and blockers in Org-mode:

- first of all, I believe we can keep the question of adressing
   an item (using GUIDs or relations like "next TODO item in the 
subtree")
   completely separate from the mechanism by which Org-mode triggers an 
action.

- concerning the TRIGGER proposal by John, and the TRIGGER/BLOCKER 
functionality
   discussed later:  In Emacs terms, this seems to translate into a 
*hook*
   that is called at the right moment.  I'd say that a single hook is 
enough.
   The right moment to call it would be when Org-mode has figured out 
everything
   about a change that is about to occur, but before actually doing it.
   We can be general what kind of change this could be, a TODO state 
change,
   adding a tag, setting a property, changing the priority, anything 
really.

   So we would have a property that contains a Lisp form, and that lisp 
form would
   be evaluated at that moment.
   TRIGGER would then mean to perform actions in other entries.
   BLOCKER would mean to query other entries for information, and, if 
necessary,
   abort the current action, for example by throwing to a specified 
catch form.
   Obviously, if you nee both triggers and blockers, the blockers need 
to run
   first, but we don't need separate properties/functions for this.

   The detailed implementation would then be a number of Lisp functions 
that
   take as arguments a *single* structure that contains all the info of 
the change,
   for example a property list like

       (list :type 'TODOSTATE :from nil %to "INPROGRESS" ....)

   Compared to John's proposal with two lists describing previous and 
new state,
   the difference is that my list describes a *change*, while Johns 
function would
   have to figure out if the entry info actually changed.  But for the 
rest it is
   similar.

   The "language" that has been discussed could be moved into the call
   and therefore set no restrictions what so ever.  For example

   :PROPERTIES:
   :TRIGGER: '(progn
               (org-block-unless 'done #address1 #address2 #address3)
               (org-trigger 'todo "RESUME" #address4))
   :END:

It seems to me that everything people have been discussing here could
be implemented based on such a scheme.

Security is an issue, yes.  We could diffuse it a bit by blessing some
functions, but it would not be easy to totally get rid of this problem.
The best I can think of is to give the user a choice whether to execute
such code or not.

- Carsten


On Oct 9, 2007, at 4:15, Bastien wrote:

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

--
Carsten Dominik
Sterrenkundig Instituut "Anton Pannekoek"
Universiteit van Amsterdam
Kruislaan 403
NL-1098SJ Amsterdam
phone: +31 20 525 7477