depending TODOs, scheduling following TODOs automatically

depending TODOs, scheduling following TODOs automatically

[Rainer Stengele]

Hi!

Having a TODO which depends on an earlier TODO I would like to trigger the timestamped scheduling of
the following TODO when the former is DONE.
How do you folks handle such dependencies?
Could any automatic process be implemented?


* TODO job 1
    SCHEDULED: <2007-10-12 Fr>
* TODO job 2 (followup of job 1)
* TODO job 3 (followup of job 2)



rainer

Re: depending TODOs, scheduling following TODOs automatically

[Denis Bueno]

On 10/8/07, Rainer Stengele <rainer.stengele@diplan.de> wrote:
> Hi!
>
> Having a TODO which depends on an earlier TODO I would like to trigger the timestamped scheduling of
> the following TODO when the former is DONE.

I second this request.  I often like to schedule a workflow where task
A must precede B which precedes C, &c., but I'd rather not see that B
and C are scheduled until and (and B, respectively) are DONE.  Seems
like a very useful way to organise.

-- 
                              Denis

Re: depending TODOs, scheduling following TODOs automatically

[Russell Adams]

Lets make that more generic. How do you organize your dependencies
anyway? The basic hierarchy can't always be setup in order.

One of the things I'd considered is an optional GUID property for each
todo, and then a DEPENDS property with the GUID of any (potentially
multiple?) dependencies.

There'd need to be a way to navigate this list, though goto via GUID
link would work nicely. It may even be appropriate to list the current
TODO as BLOCKED until all dependencies are DONE.

Russell

On Mon, Oct 08, 2007 at 09:26:58AM -0400, Denis Bueno wrote:
> On 10/8/07, Rainer Stengele <rainer.stengele@diplan.de> wrote:
> > Hi!
> >
> > Having a TODO which depends on an earlier TODO I would like to trigger the timestamped scheduling of
> > the following TODO when the former is DONE.
> 
> I second this request.  I often like to schedule a workflow where task
> A must precede B which precedes C, &c., but I'd rather not see that B
> and C are scheduled until and (and B, respectively) are DONE.  Seems
> like a very useful way to organise.
> 
> -- 
>                               Denis
> 
> 
> _______________________________________________
> 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
------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: depending TODOs, scheduling following TODOs automatically

[Russell Adams]

I know I'm replying to myself, but I had an idea.

If a link could show the state of a linked TODO, that would make for a
good visualization. I could then follow the link and just adjust my
order to account for dependencies. It sounds like a more "permanent"
agenda view that you could edit to get the right order.

Ie:

* Things to do in reverse order
** TODO One
** TODO Two
** TODO Three

* Implementation Order

 TODO Three
 TODO Two
 TODO One



On Mon, Oct 08, 2007 at 08:43:53AM -0500, Russell Adams wrote:
> Lets make that more generic. How do you organize your dependencies
> anyway? The basic hierarchy can't always be setup in order.
> 
> One of the things I'd considered is an optional GUID property for each
> todo, and then a DEPENDS property with the GUID of any (potentially
> multiple?) dependencies.
> 
> There'd need to be a way to navigate this list, though goto via GUID
> link would work nicely. It may even be appropriate to list the current
> TODO as BLOCKED until all dependencies are DONE.
> 
> Russell
> 
> On Mon, Oct 08, 2007 at 09:26:58AM -0400, Denis Bueno wrote:
> > On 10/8/07, Rainer Stengele <rainer.stengele@diplan.de> wrote:
> > > Hi!
> > >
> > > Having a TODO which depends on an earlier TODO I would like to trigger the timestamped scheduling of
> > > the following TODO when the former is DONE.
> > 
> > I second this request.  I often like to schedule a workflow where task
> > A must precede B which precedes C, &c., but I'd rather not see that B
> > and C are scheduled until and (and B, respectively) are DONE.  Seems
> > like a very useful way to organise.
> > 
> > -- 
> >                               Denis
> > 
> > 
> > _______________________________________________
> > 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
> ------------------------------------------------------------------
> Russell Adams                            RLAdams@AdamsInfoServ.com
> 
> PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/
> 
> Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
> 
> 
> _______________________________________________
> 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
------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: depending TODOs, scheduling following TODOs automatically

[Carsten Dominik]

On Oct 8, 2007, at 15:52, Russell Adams wrote:

> I know I'm replying to myself, but I had an idea.
>
> If a link could show the state of a linked TODO, that would make for a
> good visualization. I could then follow the link and just adjust my
> order to account for dependencies. It sounds like a more "permanent"
> agenda view that you could edit to get the right order.
>
> Ie:
>
> * Things to do in reverse order
> ** TODO One
> ** TODO Two
> ** TODO Three
>
> * Implementation Order
>
>  TODO Three
>  TODO Two
>  TODO One

I don't know what others think, but I did not understand a single word 
of this message :-)  Could you please be a bit more verbose?

- Carsten

>
>
>
> On Mon, Oct 08, 2007 at 08:43:53AM -0500, Russell Adams wrote:
>> Lets make that more generic. How do you organize your dependencies
>> anyway? The basic hierarchy can't always be setup in order.
>>
>> One of the things I'd considered is an optional GUID property for each
>> todo, and then a DEPENDS property with the GUID of any (potentially
>> multiple?) dependencies.
>>
>> There'd need to be a way to navigate this list, though goto via GUID
>> link would work nicely. It may even be appropriate to list the current
>> TODO as BLOCKED until all dependencies are DONE.
>>
>> Russell
>>
>> On Mon, Oct 08, 2007 at 09:26:58AM -0400, Denis Bueno wrote:
>>> On 10/8/07, Rainer Stengele <rainer.stengele@diplan.de> wrote:
>>>> Hi!
>>>>
>>>> Having a TODO which depends on an earlier TODO I would like to 
>>>> trigger the timestamped scheduling of
>>>> the following TODO when the former is DONE.
>>>
>>> I second this request.  I often like to schedule a workflow where 
>>> task
>>> A must precede B which precedes C, &c., but I'd rather not see that B
>>> and C are scheduled until and (and B, respectively) are DONE.  Seems
>>> like a very useful way to organise.
>>>
>>> -- 
>>>                               Denis
>>>
>>>
>>> _______________________________________________
>>> 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
>> ------------------------------------------------------------------
>> Russell Adams                            RLAdams@AdamsInfoServ.com
>>
>> PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/
>>
>> Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
>>
>>
>> _______________________________________________
>> 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
> ------------------------------------------------------------------
> Russell Adams                            RLAdams@AdamsInfoServ.com
>
> PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/
>
> Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
>
>
> _______________________________________________
> 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

Re: depending TODOs, scheduling following TODOs automatically

[Russell Adams]

On Mon, Oct 08, 2007 at 09:48:28PM +0200, Carsten Dominik wrote:
> 
> On Oct 8, 2007, at 15:52, Russell Adams wrote:
> 
> >I know I'm replying to myself, but I had an idea.
> >
> >If a link could show the state of a linked TODO, that would make for a
> >good visualization. I could then follow the link and just adjust my
> >order to account for dependencies. It sounds like a more "permanent"
> >agenda view that you could edit to get the right order.
> >
> >Ie:
> >
> >* Things to do in reverse order
> >** TODO One
> >** TODO Two
> >** TODO Three
> >
> >* Implementation Order
> >
> > TODO Three
> > TODO Two
> > TODO One
> 
> I don't know what others think, but I did not understand a single word 
> of this message :-)  Could you please be a bit more verbose?
> 
> - Carsten

I don't use links often... If I could have a link to another TODO
item, but have the visible portion of the link display the status of
the target TODO item.

Ie:

* Things to do in reverse order
** TODO One
** TODO Two
** DONE Three

* Implementation Order

 [[file:..*Three][DONE Three]]
 [[file:..*Two][TODO Two]]
 [[file:..*One][TODO One]]

This way I can follow the link from the implementation order to the
right todo item, the part that is missing is an automated state update
regarding the TODO linked to.

Better? ;]

Russell


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: depending TODOs, scheduling following TODOs automatically

[Carsten Dominik]

On Oct 8, 2007, at 22:12, Russell Adams wrote:
>
> I don't use links often... If I could have a link to another TODO
> item, but have the visible portion of the link display the status of
> the target TODO item.
>
> Ie:
>
> * Things to do in reverse order
> ** TODO One
> ** TODO Two
> ** DONE Three
>
> * Implementation Order
>
>  [[file:..*Three][DONE Three]]
>  [[file:..*Two][TODO Two]]
>  [[file:..*One][TODO One]]
>
> This way I can follow the link from the implementation order to the
> right todo item, the part that is missing is an automated state update
> regarding the TODO linked to.
>
> Better? ;]

Yes, this is clearer, thank you.

- Carsten

Re: depending TODOs, scheduling following TODOs automatically

[Eddward DeVilla]

    I've been waiting to see if org might develop something like todo
dependency ordering.  Seems like one could use this with and estimated
time to complete a todo item to generate a milestone table or more
easily estimate how long a group of tasks will require to complete or
when the soonest a given step could begin.
    I'm not sure if I like having the unique ID property for the todo.
 With drawers, it would be hidden at least and org can probably make
sure they really are unique.  Attaching a unique ID to todos could
probably be useful in other ways to.  It just doesn't feel right for a
format where pretty much every thing in the files tend to be fit for
human consumption.  I guess I'm assuming the ID would just be a
number, it could be something a little more readable/meaningful.

        You could allow (but not require) an arbitrary label property
on each todo item.

        You could allow multiple dependencies (a list property?) where
the dependency is named via the label (requiring that any todo item
that is depended upon have a label).

        You could have an operation in or that will insert a label
property into the PROPERTIES drawer for the current todo item for the
user, possibly prompting the user for a label or automatically
generating a UID based on prefix key or customization.

        Lastly you could have operations to copy labels and
dependencies and paste them into and delete them from dependency lists
(but not labels) in org buffers and agenda buffers to edit
dependencies.

    I like that the label described above could be something the user
defines or it could just random looking uid.  I don't know if it would
ever be used that way.  I'm also not sure if an item should be allow
more than one label.  It would be like a software package the
'provides' more than one feature.  I'm not sure it make sense in
project planning.  Would it be valid to name dependencies before you
know where they will be addressed?  I know I tend to determine
dependencies well before I know when or will they get addressed, but
then I don't claim to know what I'm doing most of the time.

Edd

On 10/8/07, Russell Adams <RLAdams@adamsinfoserv.com> wrote:
> Lets make that more generic. How do you organize your dependencies
> anyway? The basic hierarchy can't always be setup in order.
>
> One of the things I'd considered is an optional GUID property for each
> todo, and then a DEPENDS property with the GUID of any (potentially
> multiple?) dependencies.
>
> There'd need to be a way to navigate this list, though goto via GUID
> link would work nicely. It may even be appropriate to list the current
> TODO as BLOCKED until all dependencies are DONE.
>
> Russell
>
> On Mon, Oct 08, 2007 at 09:26:58AM -0400, Denis Bueno wrote:
> > On 10/8/07, Rainer Stengele <rainer.stengele@diplan.de> wrote:
> > > Hi!
> > >
> > > Having a TODO which depends on an earlier TODO I would like to trigger the timestamped scheduling of
> > > the following TODO when the former is DONE.
> >
> > I second this request.  I often like to schedule a workflow where task
> > A must precede B which precedes C, &c., but I'd rather not see that B
> > and C are scheduled until and (and B, respectively) are DONE.  Seems
> > like a very useful way to organise.
> >
> > --
> >                               Denis
> >
> >
> > _______________________________________________
> > 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
> ------------------------------------------------------------------
> Russell Adams                            RLAdams@AdamsInfoServ.com
>
> PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/
>
> Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
>
>
> _______________________________________________
> 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
>

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

Implementing tasks-dependencies sounds pretty exciting!

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?

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[Adam Spiers]

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.

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

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

Re: depending TODOs, scheduling following TODOs automatically

[John Wiegley]

Bastien <bzg@altern.org> writes:

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

How about just having generalized Lisp triggers:

  :PROPERTIES:
  :TRIGGER: (lambda (previous new)
               (if (string= (assoc "TODO" new) "DONE")
                   (org-find-and-schedule "regexp matching task" date)))
  :END:

In this example, previous and new are associative lists containing all of the
state information applicable to an entry.

This kind of mechanism would allow Carsten to come up with a small library of
org-mode Lisp functions for programmatically manipulating tasks simply by
specifying a regular expression, or a relative offset, to "locate" them.

I would far prefer this to a specialized syntax, which in the end would
require so complexity as to become a domain-specific language in itself.

John

Re: depending TODOs, scheduling following TODOs automatically

[Eddward DeVilla]

On 10/8/07, John Wiegley <johnw@newartisans.com> wrote:
> How about just having generalized Lisp triggers:
[snip]

This could be dangerous.  Org file are (most) text.  The more code you
allow to be embedded, the more of a vector org-mode becomes for trojan
horse attacks.  Of course I've been using lisp in tables formulas more
and more, so I am a hypocrite.  I'd love a way to embed lisp trigger
into properties, but they probably ought to be in the .emacs or the
like.

Edd

Re: depending TODOs, scheduling following TODOs automatically

[Richard G Riley]

"Eddward DeVilla" <eddward@gmail.com> writes:

> On 10/8/07, John Wiegley <johnw@newartisans.com> wrote:
>> How about just having generalized Lisp triggers:
> [snip]
>
> This could be dangerous.  Org file are (most) text.  The more code you
> allow to be embedded, the more of a vector org-mode becomes for trojan
> horse attacks.  Of course I've been using lisp in tables formulas more
> and more, so I am a hypocrite.  I'd love a way to embed lisp trigger
> into properties, but they probably ought to be in the .emacs or the
> like.
>
> Edd

I'm interested in this. Why would an Org file with permissions like 700
be any more virus friendly than an .emacs with the same permissions? Een
taking the windows case, a .emacs is executed each and every time, but
the org file only when loaded and acted upon.

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

Re: depending TODOs, scheduling following TODOs automatically

[Eddward DeVilla]

On 10/9/07, Richard G Riley <rileyrgdev@googlemail.com> wrote:
> I'm interested in this. Why would an Org file with permissions like 700
> be any more virus friendly than an .emacs with the same permissions? Een
> taking the windows case, a .emacs is executed each and every time, but
> the org file only when loaded and acted upon.

Perhaps it an over reaction on my part.  I know the occasional
org-file gets posted on this list.  I'd like to see org catch on and
see more info made available in org files.  I don't normally send my
.emacs file(s) to folks.  That's my custom setup.  (Though once in a
while someone does copy it.)

If org becomes popular enough that people pass data around in it, then
it could be more of an issue.  Especially since I think the triggers
would be in drawers which are all always hidden unless you go and
explicitly open each one.  So you have hidden code in a powerful
language.  It's not very hidden and I know it not likely that org's
format would catch on the way I'd like.

Anyhow, I'm not saying don't do it.  I just wanted to be sure it
wasn't overlooked.

Edd

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

"Eddward DeVilla" <eddward@gmail.com> writes:

> If org becomes popular enough that people pass data around in it, then
> it could be more of an issue.  Especially since I think the triggers
> would be in drawers which are all always hidden unless you go and
> explicitly open each one.

The pool of (possibly) triggered actions would have two purposes then:

- make the list of current triggers for this file *visible*;
- selectively let the user prevent an action to be triggered.

And as proposed before, we could also have a set of `safe-org-triggers'.

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

"Eddward DeVilla" <eddward@gmail.com> writes:

> This could be dangerous.  Org file are (most) text.  The more code you
> allow to be embedded, the more of a vector org-mode becomes for trojan
> horse attacks.

Well, thinking of org-mode as a vector of trojan horse attacks sounds
like science fiction to me :)

Anyway, as I said, we could store the triggered actions in a pool and
ask the user if he want to perform them.  Of course the user would be
allowed to turn a set of actions "safe" (see `safe-local-eval-forms')

Not that a problem IMO.

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

John Wiegley <johnw@newartisans.com> writes:

> Bastien <bzg@altern.org> writes:
>
>> 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.
>
> How about just having generalized Lisp triggers:
>
>   :PROPERTIES:
>   :TRIGGER: (lambda (previous new)
>                (if (string= (assoc "TODO" new) "DONE")
>                    (org-find-and-schedule "regexp matching task" date)))
>   :END:
>
> In this example, previous and new are associative lists containing all of the
> state information applicable to an entry.

Yes, I like this very much.

We could have both a TRIGGER and a BLOCKER property.  The first one
would trigger actions on tasks.  The second one wouldn't let a change
appear on the task unless some tasks are in a specific state.

I tried to figure out how we could emulate the job of the BLOCKER
property with only TRIGGER and an option like `org-check-triggers',
saying that the action the TRIGGER is supposed to perform won't be
allowed if it's not performed *by the TRIGGER* itself -- therefore
enabling us to use "rigid" TRIGGERS and some kind of dependencies
checks.  

But I don't think it's really feasible -- not even a good idea.

> This kind of mechanism would allow Carsten to come up with a small
> library of org-mode Lisp functions for programmatically manipulating
> tasks simply by specifying a regular expression, or a relative offset,
> to "locate" them.

Yes, sounds like a good idea.

> I would far prefer this to a specialized syntax, which in the end would
> require so complexity as to become a domain-specific language in itself.

I do agree the syntax I proposed was somewhat bloat.  Consider it
brain-dust after excitment! 

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[Carsten Dominik]

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

Re: depending TODOs, scheduling following TODOs automatically

[pete phillips]

>>>>> "Carsten" == Carsten Dominik <dominik@science.uva.nl> writes:

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

I have to say that I'm a bit worried if org-mode goes in this direction.

Just because Carsten may be able to beat it into shape to do this
(albeit in very elegant lisp), it doesn't mean he should.

org-mode developed as a means of maintaining lists, and it excels at
this. Just because the GTD methodology uses the term Project doesn't
mean that we should turn org-mode into a fully fledged project planning
application. If you need project planning capability, then you probably
need all the bells and whistles that go with it - GANT and PERT charts,
critical path calculations, multi-user capabilities etc.  

My concern is that *very* few people need that type of functionality,
and if you do, there are now some very good applications now under
GNU/Linux to choose from.  

org-mode is a superb PIM and list manager (in my view, probably about
the best there is). Just because we have one incredible hammer, let's
not start seeing everything else as a nail!

Just a personal viewpoint of course.  :-)

Pete

Re: depending TODOs, scheduling following TODOs automatically

[Sebastjan Trepca]

Hey,

I'm new here but I have to say that I totally agree with Pete.

Why not just work on integration with popular project management
tools? e.g export to Jira, Trac, ...

(btw, syncing todos with Trac tickets would really come handy :)

Sebastjan

On 10/11/07, pete phillips <pete@smtl.co.uk> wrote:
> >>>>> "Carsten" == Carsten Dominik <dominik@science.uva.nl> writes:
>
>     Carsten> First, let me say that I was surprised that quite a few
>     Carsten> people are so keen to see this kind of features.  I myself
>     Carsten> would worry a lot about spending more time to set up and
>     Carsten> maintain these connections, than I would be saving by using
>     Carsten> them.  And I am not sure if Org-mode really scales up
>     Carsten> nicely when it comes to really large projects, large number
>     Carsten> of people interacting, keeping complex GANTT charts up to
>     Carsten> date etc.  Me, I have sometimes made these charts during an
>     Carsten> initial project setup, to get a feeling what amount of time
>     Carsten> and resources would be needed, but I have never kept these
>     Carsten> complex structures alive and up to date.
>
> I have to say that I'm a bit worried if org-mode goes in this direction.
>
> Just because Carsten may be able to beat it into shape to do this
> (albeit in very elegant lisp), it doesn't mean he should.
>
> org-mode developed as a means of maintaining lists, and it excels at
> this. Just because the GTD methodology uses the term Project doesn't
> mean that we should turn org-mode into a fully fledged project planning
> application. If you need project planning capability, then you probably
> need all the bells and whistles that go with it - GANT and PERT charts,
> critical path calculations, multi-user capabilities etc.
>
> My concern is that *very* few people need that type of functionality,
> and if you do, there are now some very good applications now under
> GNU/Linux to choose from.
>
> org-mode is a superb PIM and list manager (in my view, probably about
> the best there is). Just because we have one incredible hammer, let's
> not start seeing everything else as a nail!
>
> Just a personal viewpoint of course.  :-)
>
> Pete
>
>
>
> _______________________________________________
> 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
>

Re: depending TODOs, scheduling following TODOs automatically

[Russell Adams]

On Thu, Oct 11, 2007 at 04:53:42PM +0100, pete phillips wrote:
> org-mode is a superb PIM and list manager (in my view, probably about
> the best there is). Just because we have one incredible hammer, let's
> not start seeing everything else as a nail!
> 
> Just a personal viewpoint of course.  :-)
> 
> Pete

Actually, I'd be happy being able to link to TODO's and have their
states change. You're right that the complexity can quickly grow out
of hand trying to implement project management features, however you
must realize that a tool meant to maintain personal lists of items may
eventually grow to encompass larger projects.

I think the reason this discussion took off is that if an existing
project management tool worked the way we wanted it to, this would be
a moot discussion. As it is, it appears that none of the traditional
PM style tools integrate with Org use or provide similar
functionality. I know I've been frustrated trying to export Org data
to MS Project and keep them in sync.

Russell

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: depending TODOs, scheduling following TODOs automatically

[pete phillips]

>>>>> "Russell" == Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

    Russell> however you must realize that a tool meant to maintain
    Russell> personal lists of items may eventually grow to encompass
    Russell> larger projects.

 :-)

I do realise this.  But the question that needs to be answered
is whether this is necessarily the best path ?

    Russell> I think the reason this discussion took off is that if an
    Russell> existing project management tool worked the way we wanted
    Russell> it to, this would be a moot discussion. As it is, it
    Russell> appears that none of the traditional PM style tools
    Russell> integrate with Org use or provide similar functionality. I
    Russell> know I've been frustrated trying to export Org data to MS
    Russell> Project and keep them in sync.

It could be that you are trying to use the wrong tool ? Task Juggler 

   http://www.taskjuggler.org/

is cross platform and will do all the PM you need out of the box.  As
the system is based on a text mode, I am willing to bet that you could
write some perl or other code to move your org file into it. Possibly
the other way as well.

Don't get me wrong - I have used PM tools myself for very big projects
(in fact I used to maintain the PM FAQ document on Usenet many years ago
http://www.non.com/news.answers/proj-plan-faq.html), but I just question
if org-mode is the right path to follow for this.

Let me explain my concern. If Carsten decides to move along the PM route
(and it is entirely his call), then I suspect that the amount of code
required to implement all the necessary functionality will be huge. It
would probably dwarf the present org-mode code base.

At that stage, the ability of Carsten to respond so quickly to requests
for features and bug fixes will, I think, be compromised. Also, it is
bound to have an effect on the speed of org mode. My main concern is
that the focus of org-mode will have shifted away from where I want it
to be, which I admit is a personal concern and perhaps a little selfish
:-) 

Anyway, just my thoughts.
Have a good evening all.

Pete

Re: depending TODOs, scheduling following TODOs automatically

[Russell Adams]

On Thu, Oct 11, 2007 at 06:10:50PM +0100, pete phillips wrote:
> I do realise this.  But the question that needs to be answered
> is whether this is necessarily the best path ?

It isn't necessarily. I'm just pointing out it's likely to grow as
more folks use it for larger lists. After all, most PM software
just maintains a specialized kind of list.

Yes I've looked at task juggler, and was impressed, but its overkill
for what I need. (its also GUI!)

I think the key here is that Org needs some PM-like functionality, but
I certainly wouldn't advocate trying to make Org a full PM. Org is
great for lists, notes, TODO's, etc. Ever try to take freeform notes
in MS Project? ;]

I'm interested to see where Carsten and the others take these ideas.

Russell 



------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: depending TODOs, scheduling following TODOs automatically

[pete phillips]

>>>>> "Russell" == Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

    Russell> It isn't necessarily. I'm just pointing out it's likely to
    Russell> grow as more folks use it for larger lists. After all, most
    Russell> PM software just maintains a specialized kind of list.

    Russell> Yes I've looked at task juggler, and was impressed, but its
    Russell> overkill for what I need. (its also GUI!)

Nah. It *has* a GUI, but underneath it is text based.  I've run a few
projects with it, and I know it uses text. The structure is very
simple. From the Tutorial:

    Chapter 4. Tutorial: Your First Project

    We have mentioned already that TaskJuggler uses plain text files that
    describe the project to schedule it.  As you will see now, the
    syntax of these files is easy to understand and very intuitive.

I doubt it's overkill. The nice thing about task juggler is that you can
just use as much as you need.  I have used it for some large projects
(but, like Carsten, only for the initial planning and resource
allocation phase). 

I genuinely think that if there is a band of org-moders (hmmm we could
do with a cooler collective noun I think ?)  who need PM functionality,
then a combination of org-mode and TJ with some perl glue would be
pretty good. 

    Russell> I think the key here is that Org needs some PM-like
    Russell> functionality, but I certainly wouldn't advocate trying to
    Russell> make Org a full PM. Org is great for lists, notes, TODO's,
    Russell> etc. Ever try to take freeform notes in MS Project? ;]

Nope. I don't use MS to start with.  ;-)  Also, when using TJ, I was
also able to make notes in emacs (because I was coding the TJ files in
emacs). 

Anyway, this horse is flogged to death!  If your experience of TJ is
only the GUI, I'd seriously recommend a look at the command line
mode. The nice thing about using org-mode with other programmes is that
it tends to conform to the UNIX philosophy:

     "Write programs that do one thing and do it well. Write programs to
     work together. Write programs to handle text streams, because that
     is a universal interface."


Pete

Re: depending TODOs, scheduling following TODOs automatically

[Charles Cave]

pete phillips wrote:

> I genuinely think that if there is a band of org-moders (hmmm we could
> do with a cooler collective noun I think ?)  

How about ORG-MONGERS?

Charles

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

Charles Cave <charles_cave@optusnet.com.au> writes:

> How about ORG-MONGERS?

Org-wonks!

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

> I think the key here is that Org needs some PM-like functionality, but
> I certainly wouldn't advocate trying to make Org a full PM. Org is
> great for lists, notes, TODO's, etc. Ever try to take freeform notes
> in MS Project? ;]
>
> I'm interested to see where Carsten and the others take these ideas.

Maybe I should have been soberer while trying to imagine how the
suggested features could be implemented in Org.  In fact, I just thought
it was challenging to figure out what could be the best implementation
and, while trying to write down those ideas, I surely gave the false
impression that I took for granted that Org should go that direction.

But this is, of course, questionable. 

I think this direction is the good one if:

1. people provide convincing examples on how PM-like features would be
   useful for their own use of Org;

2. the implementation does not change what people already like in Org;

3. the implementation is incremental, slowly absorbing proposals from
   people really using them.

As for 1. I can think of a very simple need I come accross quite often:

  I have a few headlines, and the first one is typically being marked
  NEXT. Once this task is done, I want the next one to be marked NEXT.
  Other example: when I cancel a headline, I want to interactively
  cancel subtasks that still populate the agenda buffer.

For 2. and 3., only Carsten can have a clear view on that ones I guess.

Regards,

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[Rainer Stengele]

Russell Adams schrieb:
> On Thu, Oct 11, 2007 at 06:10:50PM +0100, pete phillips wrote:
>> I do realise this.  But the question that needs to be answered
>> is whether this is necessarily the best path ?
> 
> It isn't necessarily. I'm just pointing out it's likely to grow as
> more folks use it for larger lists. After all, most PM software
> just maintains a specialized kind of list.
> 
> Yes I've looked at task juggler, and was impressed, but its overkill
> for what I need. (its also GUI!)
> 
> I think the key here is that Org needs some PM-like functionality, but
> I certainly wouldn't advocate trying to make Org a full PM. Org is
> great for lists, notes, TODO's, etc. Ever try to take freeform notes
> in MS Project? ;]
> 
> I'm interested to see where Carsten and the others take these ideas.
> 
> Russell 
> 
> 
> 
> ------------------------------------------------------------------
> Russell Adams                            RLAdams@AdamsInfoServ.com
> 
> PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/
> 
> Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
> 
> 
> _______________________________________________
> 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
> 

I also do not expect to grow Org into anything near a "full" PM.
But I do would be more than glad to get some basic (trigger or blocker)
functionality to model dependencies between todos.

Again, one of my main needs would be to hide todos until other todos are
in a certain state. Then show them after the trigger is pulled.
At the moment I have to a lot of todos in my agenda which I cannot work
on because of the "trigger" not ready. Or I have to "undo" the todos to
not see them and not forget to trigger them myself at the right moment.

Thats my 2 cents I stated the discussion with.


rainer

Re: depending TODOs, scheduling following TODOs automatically

[Leo]

On 2007-10-11 22:12 +0100, Rainer Stengele wrote:
> I also do not expect to grow Org into anything near a "full" PM.
> But I do would be more than glad to get some basic (trigger or blocker)
> functionality to model dependencies between todos.

I'd rather org stays as a PIM not PM; there are tons of PMs, please use
them.

> Again, one of my main needs would be to hide todos until other todos
>are
> in a certain state. Then show them after the trigger is pulled.
> At the moment I have to a lot of todos in my agenda which I cannot work
> on because of the "trigger" not ready. Or I have to "undo" the todos to
> not see them and not forget to trigger them myself at the right moment.
>
> Thats my 2 cents I stated the discussion with.
>
>
> rainer

-- 
.:  Leo  :.  [ sdl.web AT gmail.com ]  .:  [ GPG Key: 9283AA3F ]  :.

       Use the most powerful email client -- http://gnus.org/

Re: Re: depending TODOs, scheduling following TODOs automatically

[Piotr Zielinski]

Hi,

I am generally against introducing very specialized features to
org-mode, for the same reasons as described by others in this thread.
The power of org-mode lies in simplicify of the model it offers:
information is a collection of lists that can be queried in various
ways.

This model is simple yet powerful.  For example, org-mode can be used
not only to store ordinary tasks ("pay rent", every month), but also
meta-tasks concerning the org-file itself ("make sure there are no
stuck projects", every week).  I find this simple idea of storing
meta-tasks very useful.  It gives your org-file "life", making it the
single point of trust.  As long as you remember to check your org-mode
every day, you will never forget anything.  Instead of following the
books that tell you to "develop a habit of ..." just put this habit as
an repetitive task in org-mode.

Back to task dependencies.  I use three tags: NEXT for enabled
actions, TODO for actions that wait for the previous one on the list,
and WAITING for actions that wait for something else.  Whenever an
action is completed, you can easily check whether the next TODO should
be enabled (changed to NEXT) or not.

WAITING actions (with dependencies across different lists) are more
tricky, but in my experience, are quite rare.  Here, if you know that
completing task A will enable task Q in another part of the file,
insert a meta-task "TODO enable [[Q]]" just after A.  No special
functionality needed, just standard linking.

Of course there are some cases in which this scheme doesn't work, but
these are not many, and I don't believe making them work automatically
is worth the effort.  This is because, in my case, most of the WAITING
actions rely on external triggers (email, phone call), which are
simply not automatable.

Piotr

Re: Re: depending TODOs, scheduling following TODOs automatically

[Eddward DeVilla]

Well, I think I'm going to try something else to get the task
dependencies I'm after.  I'm using a BLOCKED tag now.  I'm thinking
I'll go with a BLOCKED property followed by the list of blockers.
I'll probably use links there, but I'll have to find a way to make
that less fragile with the dynamic portions of the heading.  I wasn't
looking for any automatic state changes myself, so that would pretty
much cover it.  I'll probably be able to make a dynamic block that
will generate a table with the tasks sorted parent first or sorted by
which task is blocking the most other tasks, if I care enough.

I can't say I have any plans to use triggers, but will they really
hurt anything?  I mean if it makes the code a mess then that wouldn't
be good.  But frankly, I have no need for the GTD 'find a stuck
project' stuff, and it hasn't been a problem for me.

Edd

Re: Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

"Eddward DeVilla" <eddward@gmail.com> writes:

> I can't say I have any plans to use triggers, but will they really
> hurt anything?  I mean if it makes the code a mess then that wouldn't
> be good.  But frankly, I have no need for the GTD 'find a stuck
> project' stuff, and it hasn't been a problem for me.

I feel quite the same.

People love Org because of its "simplicity".  But we should call it
"efficiency" rather than "simplicity", since what we really like in 
it is the fact that it makes complex actions easily achievable.

For example, both org-remember-templates and org-agenda-custom-commands
can be very complex variables, yet Org lets you configure them the way
you want so that using them becomes very "simple".

I think it would be the same for the trigger stuff: finding your way
through the best configuration for *you* would be a rather complex
process, but using them to perform the simple actions that you need
would not be that complex.

BTW, I don't see the point behing the argument: "I'm using Org for
simple project management and XXX for complex project management, so
please keep Org as simple as it is."  If both tools let you manage
complex projects, there will compete in the same area and that will be a
problem for *you*.  But not for the software itself, and not for people
that use only Org (and might be tempted to use it for more complex PM.)

My 2 cents,

-- 
Bastien

Re: Re: depending TODOs, scheduling following TODOs automatically

[Jason F. McBrayer]

Rainer Stengele <rainer.stengele@yahoo.de> writes:

> I also do not expect to grow Org into anything near a "full" PM.
> But I do would be more than glad to get some basic (trigger or blocker)
> functionality to model dependencies between todos.

I would think that setting these up initially would require as much
work and attention as simply managing them manually.

> Again, one of my main needs would be to hide todos until other todos
> are in a certain state. Then show them after the trigger is pulled.
> At the moment I have to a lot of todos in my agenda which I cannot
> work on because of the "trigger" not ready. Or I have to "undo" the
> todos to not see them and not forget to trigger them myself at the
> right moment.

What I do is mark tasks that can't be done yet as either NEEDSPREREQ
or WAITING, or put them in my SomedayMaybe.org file if there's no
possibility I'll get to them before my next weekly review.  I only
look at NEXTACTION tasks when I'm choosing a task to do, and when I
complete a task, I look at its project to see if any NEEDSPREREQ tasks
can now be done.  If so, I change those to NEXTACTION.

Yes, it would be possible to annotate these with a hook of some kind
so that they are changed from NEEDSPREREQ to NEXTACTION
automatically.  But my feeling is that doing that would frontload the
planning process too much, take just as much time/attention, and
overall interfere with getting things done.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray@carcosa.net  |
| If someone conquers a thousand times a thousand others in |
| battle, and someone else conquers himself, the latter one |
| is the greatest of all conquerors.  --- The Dhammapada    |

Re: depending TODOs, scheduling following TODOs automatically

[Jason F. McBrayer]

pete phillips <pete@smtl.co.uk> writes:

> org-mode developed as a means of maintaining lists, and it excels at
> this. Just because the GTD methodology uses the term Project doesn't
> mean that we should turn org-mode into a fully fledged project
> planning application. If you need project planning capability, then
> you probably need all the bells and whistles that go with it - GANT
> and PERT charts, critical path calculations, multi-user capabilities
> etc.

I agree.  If you're using a GTD-like methodology, all you really need
is something that is good at maintaining lists of things (and
generating cross-cutting lists of things like project vs. context).
If you are using a day-planner methodology, all you really need is to
be able to maintain dated lists with attached statuses.  Org-mode is
really good for both of these things.

Once you get into "enterprise" (read as over-bureaucratized) project
planning, then you really need software designed for the bureaucratic
requirements of your organization, or for your organziation's
bureaucracy to be built around something like MS-Project.  I don't
think it's a good idea for org-mode to try to support this type of
work.  Gnome Planner might be a workable tool for this kind of job.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray@carcosa.net  |
| If someone conquers a thousand times a thousand others in |
| battle, and someone else conquers himself, the latter one |
| is the greatest of all conquerors.  --- The Dhammapada    |

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

Carsten Dominik <dominik@science.uva.nl> writes:

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

I guess some of us were waiting for that -- thanks for sorting this
out :)

> First, let me say that I was surprised that quite a few people are so
> keen to see this kind of features.

Well, maybe there are too few tutorials out there demonstrating how
people actually use Org, but everytime someone sends an example I'm
amazed how this example looks so "personal" and add something new to
what I could imagine. 

Given the number of different persons using Org (at least the number of
emacs-orgmode@gnu.org subscribers?) I wouldn't be surprised that people
come up with clever use of TRIGGERS in their own planning habits.  Even
better if they share it through tutorials...

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

100% agreed (see my previous post.)

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

Just to make things perfectly clear - here is the process (as I
understand it) :

1. describe the last change performed on a headline in a Lisp form
2. feed any TRIGGER with the Lisp form from 1. and perform actions

Is that right?  

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

The uncertainty of my understanding relies on the fact that I'm not sure
whether this implementation is supposed to describe the TRIGGER function
or the Lisp form from the first step of the process, as described above.

Thanks for any further clarification!

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[John Wiegley]

Carsten Dominik <dominik@science.uva.nl> writes:

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

I agree that if we keep making org-mode smarter and smarter, it will start to
become a bear that is overly complicated -- and in the world of task
management, complexity is death.

I use a dedicated Project Management application when I need scheduling and
management of complex time and resource dependencies (Merlin, from
http://merlin2.net).  I setup a proposal for a client, and then I use Merlin
to record the time spent, by capturing moments with timeclock.el and entering
the resulting blocks via the Merlin interface.  It takes time, but the value
to me and my customer of knowing where we stand and when things should
complete is definitely worth the effort (and software cost!).

But with org-mode, I'm not reporting to other people.  I want something light
and agile.  This is the first task management scheme *in my life* that I've
used daily for more than 3 months.  That is saying something, let me tell you.
I've even written my own systems still in use by other people (see Emacs
Planner)!!

In fact, I would probably say that before the year is out, org-mode's
interface and basic data structures should reach Feature Complete status.
I think we still need more hooks, for user customization, and several more
"library API functions" to make writing those customizations easier; but in
terms of the core package, I can't see how to improve on perfection from here.

John

Re: depending TODOs, scheduling following TODOs automatically

[Eddward DeVilla]

On 10/8/07, Bastien <bzg@altern.org> wrote:
> Implementing tasks-dependencies sounds pretty exciting!
>
> 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
> `----
>
[:snip:]
> What do you think?

My only real issue is that I tend to think of task dependencies in
terms of the other tasks a given task is waiting on rather than what
other tasks are waiting on a given task.  This feels a little backward
to me, but I could still use it.  I'd still have to think about how to
use this to make projections, but all the info is there for that.

Edd

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

"Eddward DeVilla" <eddward@gmail.com> writes:

> My only real issue is that I tend to think of task dependencies in
> terms of the other tasks a given task is waiting on rather than what
> other tasks are waiting on a given task.  

Ok, then:

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

  => becomes TODO when previous tasks is DONE.

> This feels a little backward to me, but I could still use it.  I'd
> still have to think about how to use this to make projections, but all
> the info is there for that.

Sure!

Two ideas again:

1) one aspect of Org is that it is very *fast*; we can change the TODO
   state of an item with just one keystroke.  Making this change trigger
   actions should require some kind of double-check, otherwise we could
   end up with a lot of changes that we're not fully aware of.
   
   One way to check the triggered changes is to build an actions pool
   gathering all actions to be performed, then ask the user if he wants
   to perform them.

2) In my proposal, the actions are just triggered by TODO state changes.
   But each action could affect or be affected by any property.

* Task A
  :PROPERTIES:
  :COLOR: red
  :END:

* Task B
  :PROPERTIES:
  :>TODO: {COLOR 'previous "green"}
  :END:

  => becomes TODO when previous tasks property COLOR is "green".

...

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[Russell Adams]

[-- Attachment #1.1: Type: text/plain, Size: 1242 bytes --]

I love this discussion on properties for dependencies, but does anyone
have a suggestion on how to visualize it?

After you setup all these triggers, you still need a central place to
view the overview and steps involved (I'm thinking project management
specifically).

My most common use of org is project management, with one org file per
project, and there are always distinct phases for primary headers
(Client, Overview, Inventory, Implementation, Documentation,
Timecard). Often, the order subitems need to be accomplished in is
different than the order of the outline.

Part of the original properties discussion revolved around project
management, dependencies, DURATION, and the ability to see a timeline
based on relative duration instead of schedule.

Would an updated agenda view suffice? Would we need a way to link to
items and manually maintain order? Will our heros finally subdue the
evil Dr. Klan? Will the mysterious Gantt chart ever emerge?

Thanks!


------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 204 bytes --]

_______________________________________________
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

Re: depending TODOs, scheduling following TODOs automatically

[Eddward DeVilla]

On 10/8/07, Russell Adams <RLAdams@adamsinfoserv.com> wrote:
> I love this discussion on properties for dependencies, but does anyone
> have a suggestion on how to visualize it?
>
> After you setup all these triggers, you still need a central place to
> view the overview and steps involved (I'm thinking project management
> specifically).

I'm not even thinking triggers as much as seeing things marked Blocked
if their dependencies are not met.

> My most common use of org is project management, with one org file per
> project, and there are always distinct phases for primary headers
> (Client, Overview, Inventory, Implementation, Documentation,
> Timecard). Often, the order subitems need to be accomplished in is
> different than the order of the outline.

In projects, my sections are
    - quick info --  a table with things like defect or request
tracking info, start date, estimated time,  date testing begins and
date actually completed.  I may have other simple cut and paste info
there.  This stuff is slowly moving into the PROPERTIES drawer.
    - status log -- a list with entries that begin with an inactive
date and whatever interesting things happened on that day.  A diary of
sorts.
    - investigating -- a hierarchy of checkbox lists (I use plain list
folding) of questions I need answers to.
    - work -- a hierarchy of checkbox lists of things that actually
need to be done.
    - verification -- a hierarchy of checkbox lists of what needs to
be done to verify that things got done right.  (Testing)

I'm now at the point that I have several such projects in flight that
can block one another.  One thing I think I'm eventually going to have
to do is replace my checkbox lists to todo items lists.  Given that
multiple todo sequences are supported, that is now reasonable.

> Part of the original properties discussion revolved around project
> management, dependencies, DURATION, and the ability to see a timeline
> based on relative duration instead of schedule.
>
> Would an updated agenda view suffice? Would we need a way to link to
> items and manually maintain order? Will our heros finally subdue the
> evil Dr. Klan? Will the mysterious Gantt chart ever emerge?

    My wild imaginings were that it would develop into something
providing the info for a gantt chart.  More realistically, I was
picturing a generated table of tasks sorted by dependencies, with
estimated start and end dates filled in based on constrains imposed by
dependency ordering, hard deadlines, hard set start dates, etc.
Perhaps you could adjust ordering of task in the table when constrains
allow it and get gripe messages or red flags in impossible situations.
 Perhaps it could color items that make up a critical path.
    It could be an agenda like view with remove editing features and
highlighting effects, but I'm not sure that would be the best or most
flexible design.  Given properties and dynamic blocks, we have tools
to implement something basic outside of org-mode now.  Even a gantt
chart generator.  For me, it's a time thing.  That and my work
situation has changed dramatically and the way I planned work before
does work well in my current situation.

Edd

Re: depending TODOs, scheduling following TODOs automatically

[Russell Adams]

On Mon, Oct 08, 2007 at 10:35:33PM -0500, Eddward DeVilla wrote:
> On 10/8/07, Russell Adams <RLAdams@adamsinfoserv.com> wrote:
> In projects, my sections are
>     - quick info --  a table with things like defect or request
> tracking info, start date, estimated time,  date testing begins and
> date actually completed.  I may have other simple cut and paste info
> there.  This stuff is slowly moving into the PROPERTIES drawer.
>     - status log -- a list with entries that begin with an inactive
> date and whatever interesting things happened on that day.  A diary of
> sorts.
>     - investigating -- a hierarchy of checkbox lists (I use plain list
> folding) of questions I need answers to.
>     - work -- a hierarchy of checkbox lists of things that actually
> need to be done.
>     - verification -- a hierarchy of checkbox lists of what needs to
> be done to verify that things got done right.  (Testing)
> 
> I'm now at the point that I have several such projects in flight that
> can block one another.  One thing I think I'm eventually going to have
> to do is replace my checkbox lists to todo items lists.  Given that
> multiple todo sequences are supported, that is now reasonable.

I think the difference here is that I have settled into a routine of
grouping by logical type, not implementation order. This is why
dependencies appeal to me, because I can use them to order items
without disrupting the logical relationships.

As to Gantt, lets just dump trees into Graphviz!

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: depending TODOs, scheduling following TODOs automatically

[Eddward DeVilla]

On 10/8/07, Russell Adams <RLAdams@adamsinfoserv.com> wrote:
> On Mon, Oct 08, 2007 at 10:35:33PM -0500, Eddward DeVilla wrote:
> > I'm now at the point that I have several such projects in flight that
> > can block one another.  One thing I think I'm eventually going to have
> > to do is replace my checkbox lists to todo items lists.  Given that
> > multiple todo sequences are supported, that is now reasonable.
>
> I think the difference here is that I have settled into a routine of
> grouping by logical type, not implementation order. This is why
> dependencies appeal to me, because I can use them to order items
> without disrupting the logical relationships.

That's what I did to.  But my checkboxes lists had been very small
steps.  Projects were large collection of very small tasks.
Dependencies weren't that complicated.  The work I've moved into,
projects don't have many steps, but there are many more projects in
flight with a lot of dependencies, hard deadlines and starting a
project can be gated by arrival of hardware, or availability of people
who are too busy to write docs.

In any case, that part of the beauty of org.  It has several tools for
organizing and tracking info.  You can put them together in a lot of
different and useful ways.  The list of tools keep growing and Carsten
does an excellent job of keeping things consistent, easy to use and
independent.  It's rare that you have to learn a multiple features
just to use the one you want.  Yet the all interact well.  You can
learn it a piece at a time.

I've been dying to see dependency ordering added to that list.  Sounds
like there is some use for dependency based triggering.  They both
could be cool, but so far I'm not really attached to any of the
suggested implementations yet.

Edd

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

> As to Gantt, lets just dump trees into Graphviz!

Gantt charts could be achieved with TRIGGER/BLOCKER, trees would
requires GUID and labels.  Am I right?

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

> I love this discussion on properties for dependencies, but does anyone
> have a suggestion on how to visualize it?

Building a sparse tree with headlines that are affected by actions
possibily triggered from the current task?

> After you setup all these triggers, you still need a central place to
> view the overview and steps involved (I'm thinking project management
> specifically).

Trying to figure this out will surely help designing the right
implementation for task dependencies -- but maybe we've already
speculated way too far and should refrain from getting the whole
picture at once (I take responsability, if needed :)

> Part of the original properties discussion revolved around project
> management, dependencies, DURATION, and the ability to see a timeline
> based on relative duration instead of schedule.

Yes, I can remember that.  Good old days.

> Would an updated agenda view suffice? Would we need a way to link to
> items and manually maintain order? Will our heros finally subdue the
> evil Dr. Klan? Will the mysterious Gantt chart ever emerge?

I guess most people in this list lost their jobs already anyway.

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[Eddward DeVilla]

I'm not sure we are talking about the same things really.

On 10/8/07, Bastien <bzg@altern.org> wrote:
> "Eddward DeVilla" <eddward@gmail.com> writes:
>
> > My only real issue is that I tend to think of task dependencies in
> > terms of the other tasks a given task is waiting on rather than what
> > other tasks are waiting on a given task.
>
> Ok, then:
>
> * Task A
> * Task B
>   :PROPERTIES:
>   :>TODO: {TODO 'previous "DONE"}
>   :END:
>
>   => becomes TODO when previous tasks is DONE.

I'm not really trying to deal with linear C depends and B which
depends on A type things.  Those are easy.  I don't really need org to
change the states for me.  It's more like, work can't even begin E
until A, C & D are done.  Work can't start F until A & B are done.
The reasons for the dependencies could be anything.  (Requires a
certain person's time, requires requisite info/result generated in
other/blocking steps, artistic flare)  Given a set of such ordering
constraints, and estimated times to complete a step, what is the
soonest a step can be started or completed?  Can I use this info to
generate a table of tasks with project start and end dates?

> > This feels a little backward to me, but I could still use it.  I'd
> > still have to think about how to use this to make projections, but all
> > the info is there for that.
>
> Sure!
>
> Two ideas again:
>
> 1) one aspect of Org is that it is very *fast*; we can change the TODO
>    state of an item with just one keystroke.  Making this change trigger
>    actions should require some kind of double-check, otherwise we could
>    end up with a lot of changes that we're not fully aware of.
>
>    One way to check the triggered changes is to build an actions pool
>    gathering all actions to be performed, then ask the user if he wants
>    to perform them.
>
> 2) In my proposal, the actions are just triggered by TODO state changes.
>    But each action could affect or be affected by any property.
>
> * Task A
>   :PROPERTIES:
>   :COLOR: red
>   :END:
>
> * Task B
>   :PROPERTIES:
>   :>TODO: {COLOR 'previous "green"}
>   :END:
>
>   => becomes TODO when previous tasks property COLOR is "green".

Again, interesting, but different from where I was going.  I'm not
after editing as a side effect.  Just planning and organizing.  In a
previous message you said it isn't as complex as package dependencies.
 I guess what I was after might be.

Edd

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

"Eddward DeVilla" <eddward@gmail.com> writes:

> I'm not really trying to deal with linear C depends and B which
> depends on A type things.  Those are easy.  I don't really need org to
> change the states for me.

Okay, but this was Rainer initial request.

> It's more like, work can't even begin E until A, C & D are done.  Work
> can't start F until A & B are done.

Would the TRIGGER/BLOCKER be okay for that (assuming we can use John's
proposal of using lisp expressions and a set of predefined actions)?

> Again, interesting, but different from where I was going.  I'm not
> after editing as a side effect.  Just planning and organizing.  In a
> previous message you said it isn't as complex as package dependencies.
> I guess what I was after might be.

Yes. I thought allowing side effects (forward) and checks (backward)
would be enough - for the sake of keeping implementation simple. 

Maybe this was just an over-reaction to the idea of GUID or labels,
which sounds like we are going into trouble.

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[Eddward DeVilla]

On 10/9/07, Bastien <bzg@altern.org> wrote:
> "Eddward DeVilla" <eddward@gmail.com> writes:
> > It's more like, work can't even begin E until A, C & D are done.  Work
> > can't start F until A & B are done.
>
> Would the TRIGGER/BLOCKER be okay for that (assuming we can use John's
> proposal of using lisp expressions and a set of predefined actions)?

I think so.  It kinda clicked for me in the other thread.  I'd
probably use BLOCKER more myself, but I think I like the idea of using
it with TRIGGER to have a high level task that is marked done or would
depending on it's sub tasks.  It would be like a todo item equivalent
to the [/] & [%] tokens in plain lists.

> > Again, interesting, but different from where I was going.  I'm not
> > after editing as a side effect.  Just planning and organizing.  In a
> > previous message you said it isn't as complex as package dependencies.
> > I guess what I was after might be.
>
> Yes. I thought allowing side effects (forward) and checks (backward)
> would be enough - for the sake of keeping implementation simple.

That part of it is seems pretty simple and elegant.

> Maybe this was just an over-reaction to the idea of GUID or labels,
> which sounds like we are going into trouble.

GUIDs did sound a little off for org.  Labels would introduce a
management /maintenance problem for the user.  I felt I needed
something to built my dependency relations with.  It's hard to
'address' a todo item.  Link's might be the best thing we have for
that.

For me, linear ordering would not be enough and requiring the
hierarchy to model the dependencies will require me to break up tasks
that logically belong together.  It just might be that it's not time
to address that though.

Edd.

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

"Eddward DeVilla" <eddward@gmail.com> writes:

> It's hard to 'address' a todo item.  

Not that hard: [[*Test%20headline]]

> Link's might be the best thing we have for that.

Exactly!  And what if the text of the link could also store the todo
state value of its target (when both relevant and accessible[1])?

> For me, linear ordering would not be enough and requiring the
> hierarchy to model the dependencies will require me to break up tasks
> that logically belong together.  It just might be that it's not time
> to address that though.

The trigger/blocker functions might not be "linear" - they could check
arbitrarily for any headline's property just by searching for the task
in the buffer.

Notes: 
[1]  Their are plans for adding a TODO property to e-mail in Gnus, via
the Gnus registry.  Then storing a link from an e-mail from Gnus could
suggest its TODO property as a default TODO property in Org.

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[Russell Adams]

On Thu, Oct 11, 2007 at 01:44:11PM +0100, Bastien wrote:
> "Eddward DeVilla" <eddward@gmail.com> writes:
> 
> > It's hard to 'address' a todo item.  
> 
> Not that hard: [[*Test%20headline]]

How does that work to address this case?

* Hardware
** TODO Install
* Software
** TODO Install :ADDRESSTHISONE:
* Patches
** TODO Install

Thats why I thought a GUID property would be required.

Thanks.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

Russell Adams <RLAdams@AdamsInfoServ.Com> writes:

> How does that work to address this case?
>
> * Hardware
> ** TODO Install
> * Software
> ** TODO Install :ADDRESSTHISONE:
> * Patches
> ** TODO Install
>
> Thats why I thought a GUID property would be required.

I a sense, that shows that having a proper GUID system will only be
useful in case there are many tasks with the same name, which should
already be discouraged since headlines may show up in the agenda buffer
with no context at all.

IMO, a better rationale behind GUID is that headlines can change and
thus not be reached anymore by a search string. Having a GUID would 
fix this.  But I'm definitely not a GUID-fan, sorry :)

-- 
Bastien

Re: depending TODOs, scheduling following TODOs automatically

[Russell Adams]

> I a sense, that shows that having a proper GUID system will only be
> useful in case there are many tasks with the same name, which should
> already be discouraged since headlines may show up in the agenda buffer
> with no context at all.

I rarely have issues with conflicts in agenda. I use discreet files
for separate projects, and unique subitems are scheduled. Otherwise
I'll deal with duplicates. ;]

> 
> IMO, a better rationale behind GUID is that headlines can change and
> thus not be reached anymore by a search string. Having a GUID would 
> fix this.  But I'm definitely not a GUID-fan, sorry :)

I'm not a fan either, but recognize that it is a fast fix. You can use
a static property and simplified search (vs regexp) and know that
you've matched the correct item.

That being said, perhaps the GUID should be dynamic and similar to the
links interface. By default, no items have properties, or GUID's. If
you trigger a "save location", a GUID is added to the current item
adding a property drawer as needed. You can then choose that TODO from
a list when creating the dependency (again, just like links).

Thats what came to mind for me.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: depending TODOs, scheduling following TODOs automatically

[Eddward DeVilla]

On 10/11/07, Bastien <bzg@altern.org> wrote:
> IMO, a better rationale behind GUID is that headlines can change and
> thus not be reached anymore by a search string. Having a GUID would
> fix this.  But I'm definitely not a GUID-fan, sorry :)

In a sense that's why I said it was hard to address atodo item.  You
change a priority, a state or use a [/] token and you are hosed.  That
could be dealt with, but it's not ready yet.

Edd

Re: depending TODOs, scheduling following TODOs automatically

[John Wiegley]

Bastien <bzg@altern.org> writes:

>> * Hardware
>> ** TODO Install
>> * Software
>> ** TODO Install :ADDRESSTHISONE:
>> * Patches
>> ** TODO Install
>>
>> Thats why I thought a GUID property would be required.
>
> I a sense, that shows that having a proper GUID system will only be
> useful in case there are many tasks with the same name, which should
> already be discouraged since headlines may show up in the agenda buffer
> with no context at all.

GUIDs could always be defined using a property, to allow users to find a task
uniquely.  It doesn't have to be a canonical part of org-mode at all.

John

Re: depending TODOs, scheduling following TODOs automatically

[Christian Egli]

Eddward DeVilla <eddward <at> gmail.com> writes:

>     I've been waiting to see if org might develop something like todo
> dependency ordering.  Seems like one could use this with and estimated
> time to complete a todo item to generate a milestone table or more
> easily estimate how long a group of tasks will require to complete or
> when the soonest a given step could begin.

One of org-mode biggest strengths is its simplicity. I do not want it to turn
into a feature ridden dinosaur that is impossible to maintain.

I keep my projects simple. I plan not for the sake of planning but to get an
overview. So for dependency tracking I usually just reorder my tasks. I don't
want to fidget with my plan all day. I want to get things done :-)

To that end my plea is to keep org mode simple. That's why John's proposal
appeals to me. It is flexible and delegates the complexity to emacs lisp instead
of inventing another micro language for dependency tracking.

Christian

Re: Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

Christian Egli <christian.egli@novell.com> writes:

> To that end my plea is to keep org mode simple. That's why John's
> proposal appeals to me. It is flexible and delegates the complexity to
> emacs lisp instead of inventing another micro language for dependency
> tracking.

Again, I fully agree with that.

-- 
Bastien

Re: Re: depending TODOs, scheduling following TODOs automatically

[Eddward DeVilla]

On 10/9/07, Christian Egli <christian.egli@novell.com> wrote:
> One of org-mode biggest strengths is its simplicity. I do not want it to turn
> into a feature ridden dinosaur that is impossible to maintain.

I was hoping for something more like perl, where the easy things are
easy and the hard things are possible.  My hope for any feature in org
is that if you don't need it, it doesn't affect you and you don't need
to know it exists.

> I keep my projects simple. I plan not for the sake of planning but to get an
> overview. So for dependency tracking I usually just reorder my tasks. I don't
> want to fidget with my plan all day. I want to get things done :-)

Same here.  I'm just now in a position where I need to make sure I get
them done on time and it's starting to require some creative planning.
 A planning mistake now could really hose me 9 months from now.
Tracking complex dependency relations between tasks would go a long
way in help me see avoid such mistakes.  Obviously, not everyone is in
that boat.  I wasn't a few months ago.

> To that end my plea is to keep org mode simple. That's why John's proposal
> appeals to me. It is flexible and delegates the complexity to emacs lisp instead
> of inventing another micro language for dependency tracking.

I'm losing track of who proposed what.  I was up late last night.  I'm
liking the TRIGGER/BLOCKER idea that Bastien has been talking about,
except it lacks the ability to reference any task that isn't
immediately before, after, under or above the triggering or blocked
task.  I'm starting to think links might be to best tool in org for
identifying a task (todo item).  I'm not sold on that yet.  I may need
to give that another night.

If we go that route, I think I'd like to see a common library of code
come with org to keep us from reinvent wheels and so we can have a
subset of 'trusted' code.  (I'm security minded.  I'd hate to reinvent
the mistake of embedded VB script in documents.)

Edd

Re: Re: depending TODOs, scheduling following TODOs automatically

[Bastien]

(Sorry, I'm writing this in my very-early Eurostar, it may not be
accurate at the time it will be sent.)

"Eddward DeVilla" <eddward@gmail.com> writes:

> I'm losing track of who proposed what.  I was up late last night.  I'm
> liking the TRIGGER/BLOCKER idea that Bastien has been talking about,

Reshaping the proposal for TRIGGER/BLOCKER.  Thinking of this again, I
believe TRIGGER/BLOCKER should not be properties of a task, but rather
of one of their properties.

Then look at this:

,----
| * A task 
|   :PROPERTIES:
|   :TODO: NEXT   
|      :>: DONE (org-todo-in-subtree "DONE")
|   :END:
`----

This says: when the :TODO: property is "DONE" perform the function
(org-todo-in-subtree "DONE"), which could be a lambda expression.

And then this:

,----
| * A task 
|   :PROPERTIES:
|   :TODO: MAYBE
|      :<: NEXT (org-previous-entry-done-p)
|   :END:
`----

This says: only set the property :TODO: to "NEXT" when the previous
entry is DONE.  

The advantage of this implementation is that 

- it capture John's idea of letting lisp expression do the job of
  performing actions (and checking for conditions), replacing the 
  hairy ugly syntax I first proposed;

- it's property-based, therefore more flexible than :NEXT>: or
  even :TRIGGER: (unless we use very complex stuff in TRIGGERS)

- it looks quite *readable* (especially if indentation is in use)

- it's extensible: 
  
  :>?: trigger action interactively 
  :>!: don't trigger action interactively
  :>|: don't trigger any action after this one
  :>>: give priority to this triggered action

  ... just to give a few ideas.

> except it lacks the ability to reference any task that isn't
> immediately before, after, under or above the triggering or blocked
> task.  I'm starting to think links might be to best tool in org for
> identifying a task (todo item).  I'm not sold on that yet.  I may need
> to give that another night.

I tend to think that a labelling system should not be designed in the
same framework than the one we have been thinking about so far to add
actions to property changes.

After all, labels are only one very specific way to refer to tasks. We
can build the trigger/blocker system then make it aware of labels, if
any.  But more experienced programmers might have better insight on
this. 

Best,

-- 
Bastien