Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
Charles Cave [EMAIL PROTECTED] writes: How about ORG-MONGERS? Org-wonks! -- 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
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Carsten Dominik [EMAIL PROTECTED] 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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
pete phillips [EMAIL PROTECTED] 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[EMAIL PROTECTED] | | 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| ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
Eddward DeVilla [EMAIL PROTECTED] 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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
On Thu, Oct 11, 2007 at 01:44:11PM +0100, Bastien wrote: Eddward DeVilla [EMAIL PROTECTED] 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[EMAIL PROTECTED] 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
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 [EMAIL PROTECTED] 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
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Carsten Dominik [EMAIL PROTECTED] 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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
Carsten == Carsten Dominik [EMAIL PROTECTED] 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
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 [EMAIL PROTECTED] wrote: Carsten == Carsten Dominik [EMAIL PROTECTED] 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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
Russell == Russell Adams [EMAIL PROTECTED] 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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
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[EMAIL PROTECTED] 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
Russell Adams [EMAIL PROTECTED] 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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
Russell == Russell Adams [EMAIL PROTECTED] 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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
Eddward DeVilla [EMAIL PROTECTED] 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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
Eddward DeVilla [EMAIL PROTECTED] 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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
Russell Adams [EMAIL PROTECTED] 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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
On 10/8/07, Rainer Stengele [EMAIL PROTECTED] 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
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
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 [EMAIL PROTECTED] 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[EMAIL PROTECTED] 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[EMAIL PROTECTED] 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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[EMAIL PROTECTED] 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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
Adam Spiers [EMAIL PROTECTED] 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
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
Eddward DeVilla [EMAIL PROTECTED] 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
___
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: [Orgmode] depending TODOs, scheduling following TODOs automatically
On 10/8/07, John Wiegley [EMAIL PROTECTED] 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 ___ 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: [Orgmode] depending TODOs, scheduling following TODOs automatically
On Mon, Oct 08, 2007 at 10:35:33PM -0500, Eddward DeVilla wrote: On 10/8/07, Russell Adams [EMAIL PROTECTED] 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[EMAIL PROTECTED] 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
