From mboxrd@z Thu Jan 1 00:00:00 1970 From: Adam Spiers Subject: Re: depending TODOs, scheduling following TODOs automatically Date: Mon, 8 Oct 2007 21:26:52 +0100 Message-ID: <20071008202652.GA18426@atlantic.linksys.moosehall> References: <6dbd4d000710080626i52f0f0t9354addc33c0efee@mail.gmail.com> <20071008134353.GA10774@odin.demosthenes.org> <877ilxmimn.fsf@bzg.ath.cx> Reply-To: Adam Spiers 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 1IezBo-0001EU-7T for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 16:26:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IezBn-0001Dw-Of for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 16:26:55 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IezBn-0001Db-4W for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 16:26:55 -0400 Received: from mail.beimborn.com ([70.84.38.100]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IezBm-0006t4-Sk for emacs-orgmode@gnu.org; Mon, 08 Oct 2007 16:26:55 -0400 Received: from mail.beimborn.com (localhost.localdomain [127.0.0.1]) by mail.beimborn.com (8.12.11.20060308/8.12.8) with ESMTP id l98KQr2J020613 for ; Mon, 8 Oct 2007 15:26:53 -0500 Received: from localhost (localhost [[UNIX: localhost]]) by mail.beimborn.com (8.12.11.20060308/8.12.11/Submit) id l98KQqrD020608 for emacs-orgmode@gnu.org; Mon, 8 Oct 2007 21:26:52 +0100 Content-Disposition: inline In-Reply-To: <877ilxmimn.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: emacs-orgmode@gnu.org 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 ), 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.