Re: depending TODOs, scheduling following TODOs automatically

["Eddward DeVilla" <eddward@gmail.com>]

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