From mboxrd@z Thu Jan 1 00:00:00 1970 From: Carsten Dominik Subject: Re: depending TODOs, scheduling following TODOs automatically Date: Thu, 11 Oct 2007 16:46:33 +0200 Message-ID: <8a4d082edbc607440d4f12604b2f6332@science.uva.nl> References: <6dbd4d000710080626i52f0f0t9354addc33c0efee@mail.gmail.com> <20071008134353.GA10774@odin.demosthenes.org> <877ilxmimn.fsf@bzg.ath.cx> <20071008202652.GA18426@atlantic.linksys.moosehall> <87k5pxnicj.fsf@bzg.ath.cx> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IfzJ7-0006yp-BL for emacs-orgmode@gnu.org; Thu, 11 Oct 2007 10:46:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IfzJ6-0006yI-ET for emacs-orgmode@gnu.org; Thu, 11 Oct 2007 10:46:36 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IfzJ6-0006yE-B5 for emacs-orgmode@gnu.org; Thu, 11 Oct 2007 10:46:36 -0400 Received: from korteweg.uva.nl ([146.50.98.70]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IfzJ5-0005V5-UU for emacs-orgmode@gnu.org; Thu, 11 Oct 2007 10:46:36 -0400 In-Reply-To: <87k5pxnicj.fsf@bzg.ath.cx> 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: Bastien Cc: emacs-orgmode@gnu.org 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 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