From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: depending TODOs, scheduling following TODOs automatically Date: Tue, 09 Oct 2007 03:15:56 +0100 Message-ID: <87k5pxnicj.fsf@bzg.ath.cx> References: <6dbd4d000710080626i52f0f0t9354addc33c0efee@mail.gmail.com> <20071008134353.GA10774@odin.demosthenes.org> <877ilxmimn.fsf@bzg.ath.cx> <20071008202652.GA18426@atlantic.linksys.moosehall> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1If3hb-00061R-6F for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 21:16:03 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1If3hZ-00060p-Q1 for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 21:16:02 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1If3hZ-00060a-Ga for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 21:16:01 -0400 Received: from fk-out-0910.google.com ([209.85.128.188]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1If3hZ-0006Pj-EE for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 21:16:01 -0400 Received: by fk-out-0910.google.com with SMTP id 19so1400862fkr for ; Mon, 08 Oct 2007 18:15:59 -0700 (PDT) In-Reply-To: <20071008202652.GA18426@atlantic.linksys.moosehall> (Adam Spiers's message of "Mon, 8 Oct 2007 21:26:52 +0100") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Adam Spiers 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