emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] depending TODOs, scheduling following TODOs automatically


From: Carsten Dominik
Subject: Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Date: Thu, 11 Oct 2007 16:46:33 +0200

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 <address@hidden> 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.
address@hidden
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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]