Re: [Orgmode] Re: depending TODOs, scheduling following TODOs automatically
Eddward DeVilla [EMAIL PROTECTED] writes: I can't say I have any plans to use triggers, but will they really hurt anything? I mean if it makes the code a mess then that wouldn't be good. But frankly, I have no need for the GTD 'find a stuck project' stuff, and it hasn't been a problem for me. I feel quite the same. People love Org because of its simplicity. But we should call it efficiency rather than simplicity, since what we really like in it is the fact that it makes complex actions easily achievable. For example, both org-remember-templates and org-agenda-custom-commands can be very complex variables, yet Org lets you configure them the way you want so that using them becomes very simple. I think it would be the same for the trigger stuff: finding your way through the best configuration for *you* would be a rather complex process, but using them to perform the simple actions that you need would not be that complex. BTW, I don't see the point behing the argument: I'm using Org for simple project management and XXX for complex project management, so please keep Org as simple as it is. If both tools let you manage complex projects, there will compete in the same area and that will be a problem for *you*. But not for the software itself, and not for people that use only Org (and might be tempted to use it for more complex PM.) My 2 cents, -- 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] Re: depending TODOs, scheduling following TODOs automatically
Rainer Stengele [EMAIL PROTECTED] writes: I also do not expect to grow Org into anything near a full PM. But I do would be more than glad to get some basic (trigger or blocker) functionality to model dependencies between todos. I would think that setting these up initially would require as much work and attention as simply managing them manually. Again, one of my main needs would be to hide todos until other todos are in a certain state. Then show them after the trigger is pulled. At the moment I have to a lot of todos in my agenda which I cannot work on because of the trigger not ready. Or I have to undo the todos to not see them and not forget to trigger them myself at the right moment. What I do is mark tasks that can't be done yet as either NEEDSPREREQ or WAITING, or put them in my SomedayMaybe.org file if there's no possibility I'll get to them before my next weekly review. I only look at NEXTACTION tasks when I'm choosing a task to do, and when I complete a task, I look at its project to see if any NEEDSPREREQ tasks can now be done. If so, I change those to NEXTACTION. Yes, it would be possible to annotate these with a hook of some kind so that they are changed from NEEDSPREREQ to NEXTACTION automatically. But my feeling is that doing that would frontload the planning process too much, take just as much time/attention, and overall interfere with getting things done. -- +---+ | 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] Re: depending TODOs, scheduling following TODOs automatically
(Sorry, I'm writing this in my very-early Eurostar, it may not be accurate at the time it will be sent.) Eddward DeVilla [EMAIL PROTECTED] writes: I'm losing track of who proposed what. I was up late last night. I'm liking the TRIGGER/BLOCKER idea that Bastien has been talking about, Reshaping the proposal for TRIGGER/BLOCKER. Thinking of this again, I believe TRIGGER/BLOCKER should not be properties of a task, but rather of one of their properties. Then look at this: , | * A task | :PROPERTIES: | :TODO: NEXT | :: DONE (org-todo-in-subtree DONE) | :END: ` This says: when the :TODO: property is DONE perform the function (org-todo-in-subtree DONE), which could be a lambda expression. And then this: , | * A task | :PROPERTIES: | :TODO: MAYBE | :: NEXT (org-previous-entry-done-p) | :END: ` This says: only set the property :TODO: to NEXT when the previous entry is DONE. The advantage of this implementation is that - it capture John's idea of letting lisp expression do the job of performing actions (and checking for conditions), replacing the hairy ugly syntax I first proposed; - it's property-based, therefore more flexible than :NEXT: or even :TRIGGER: (unless we use very complex stuff in TRIGGERS) - it looks quite *readable* (especially if indentation is in use) - it's extensible: :?: trigger action interactively :!: don't trigger action interactively :|: don't trigger any action after this one :: give priority to this triggered action ... just to give a few ideas. except it lacks the ability to reference any task that isn't immediately before, after, under or above the triggering or blocked task. I'm starting to think links might be to best tool in org for identifying a task (todo item). I'm not sold on that yet. I may need to give that another night. I tend to think that a labelling system should not be designed in the same framework than the one we have been thinking about so far to add actions to property changes. After all, labels are only one very specific way to refer to tasks. We can build the trigger/blocker system then make it aware of labels, if any. But more experienced programmers might have better insight on this. Best, -- 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] Re: depending TODOs, scheduling following TODOs automatically
Hi, I am generally against introducing very specialized features to org-mode, for the same reasons as described by others in this thread. The power of org-mode lies in simplicify of the model it offers: information is a collection of lists that can be queried in various ways. This model is simple yet powerful. For example, org-mode can be used not only to store ordinary tasks (pay rent, every month), but also meta-tasks concerning the org-file itself (make sure there are no stuck projects, every week). I find this simple idea of storing meta-tasks very useful. It gives your org-file life, making it the single point of trust. As long as you remember to check your org-mode every day, you will never forget anything. Instead of following the books that tell you to develop a habit of ... just put this habit as an repetitive task in org-mode. Back to task dependencies. I use three tags: NEXT for enabled actions, TODO for actions that wait for the previous one on the list, and WAITING for actions that wait for something else. Whenever an action is completed, you can easily check whether the next TODO should be enabled (changed to NEXT) or not. WAITING actions (with dependencies across different lists) are more tricky, but in my experience, are quite rare. Here, if you know that completing task A will enable task Q in another part of the file, insert a meta-task TODO enable [[Q]] just after A. No special functionality needed, just standard linking. Of course there are some cases in which this scheme doesn't work, but these are not many, and I don't believe making them work automatically is worth the effort. This is because, in my case, most of the WAITING actions rely on external triggers (email, phone call), which are simply not automatable. Piotr ___ 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] Re: depending TODOs, scheduling following TODOs automatically
Well, I think I'm going to try something else to get the task dependencies I'm after. I'm using a BLOCKED tag now. I'm thinking I'll go with a BLOCKED property followed by the list of blockers. I'll probably use links there, but I'll have to find a way to make that less fragile with the dynamic portions of the heading. I wasn't looking for any automatic state changes myself, so that would pretty much cover it. I'll probably be able to make a dynamic block that will generate a table with the tasks sorted parent first or sorted by which task is blocking the most other tasks, if I care enough. I can't say I have any plans to use triggers, but will they really hurt anything? I mean if it makes the code a mess then that wouldn't be good. But frankly, I have no need for the GTD 'find a stuck project' stuff, and it hasn't been a problem for me. 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] Re: depending TODOs, scheduling following TODOs automatically
Christian Egli [EMAIL PROTECTED] writes: To that end my plea is to keep org mode simple. That's why John's proposal appeals to me. It is flexible and delegates the complexity to emacs lisp instead of inventing another micro language for dependency tracking. Again, I fully agree with that. -- 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] Re: depending TODOs, scheduling following TODOs automatically
On 10/9/07, Christian Egli [EMAIL PROTECTED] wrote: One of org-mode biggest strengths is its simplicity. I do not want it to turn into a feature ridden dinosaur that is impossible to maintain. I was hoping for something more like perl, where the easy things are easy and the hard things are possible. My hope for any feature in org is that if you don't need it, it doesn't affect you and you don't need to know it exists. I keep my projects simple. I plan not for the sake of planning but to get an overview. So for dependency tracking I usually just reorder my tasks. I don't want to fidget with my plan all day. I want to get things done :-) Same here. I'm just now in a position where I need to make sure I get them done on time and it's starting to require some creative planning. A planning mistake now could really hose me 9 months from now. Tracking complex dependency relations between tasks would go a long way in help me see avoid such mistakes. Obviously, not everyone is in that boat. I wasn't a few months ago. To that end my plea is to keep org mode simple. That's why John's proposal appeals to me. It is flexible and delegates the complexity to emacs lisp instead of inventing another micro language for dependency tracking. I'm losing track of who proposed what. I was up late last night. I'm liking the TRIGGER/BLOCKER idea that Bastien has been talking about, except it lacks the ability to reference any task that isn't immediately before, after, under or above the triggering or blocked task. I'm starting to think links might be to best tool in org for identifying a task (todo item). I'm not sold on that yet. I may need to give that another night. If we go that route, I think I'd like to see a common library of code come with org to keep us from reinvent wheels and so we can have a subset of 'trusted' code. (I'm security minded. I'd hate to reinvent the mistake of embedded VB script in documents.) 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
