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
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
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
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
Bastien <[EMAIL PROTECTED]> writes: >> * Hardware >> ** TODO Install >> * Software >> ** TODO Install :ADDRESSTHISONE: >> * Patches >> ** TODO Install >> >> Thats why I thought a GUID property would be required. > > I a sense, that shows that having a proper GUID system will only be > useful in case there are many tasks with the same name, which should > already be discouraged since headlines may show up in the agenda buffer > with no context at all. GUIDs could always be defined using a property, to allow users to find a task uniquely. It doesn't have to be a canonical part of org-mode at all. 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
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
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" == 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 04:53:42PM +0100, pete phillips wrote: > 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 Actually, I'd be happy being able to link to TODO's and have their states change. You're right that the complexity can quickly grow out of hand trying to implement project management features, however you must realize that a tool meant to maintain personal lists of items may eventually grow to encompass larger projects. I think the reason this discussion took off is that if an existing project management tool worked the way we wanted it to, this would be a moot discussion. As it is, it appears that none of the traditional PM style tools integrate with Org use or provide similar functionality. I know I've been frustrated trying to export Org data to MS Project and keep them in sync. 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
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
> "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
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
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 th
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
On 10/11/07, Bastien <[EMAIL PROTECTED]> wrote: > IMO, a better rationale behind GUID is that headlines can change and > thus not be reached anymore by a search string. Having a GUID would > fix this. But I'm definitely not a GUID-fan, sorry :) In a sense that's why I said it was hard to address atodo item. You change a priority, a state or use a [/] token and you are hosed. That could be dealt with, but it's not ready yet. 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
> I a sense, that shows that having a proper GUID system will only be > useful in case there are many tasks with the same name, which should > already be discouraged since headlines may show up in the agenda buffer > with no context at all. I rarely have issues with conflicts in agenda. I use discreet files for separate projects, and unique subitems are scheduled. Otherwise I'll deal with duplicates. ;] > > IMO, a better rationale behind GUID is that headlines can change and > thus not be reached anymore by a search string. Having a GUID would > fix this. But I'm definitely not a GUID-fan, sorry :) I'm not a fan either, but recognize that it is a fast fix. You can use a static property and simplified search (vs regexp) and know that you've matched the correct item. That being said, perhaps the GUID should be dynamic and similar to the links interface. By default, no items have properties, or GUID's. If you trigger a "save location", a GUID is added to the current item adding a property drawer as needed. You can then choose that TODO from a list when creating the dependency (again, just like links). Thats what came to mind for me. -- 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: > 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. I a sense, that shows that having a proper GUID system will only be useful in case there are many tasks with the same name, which should already be discouraged since headlines may show up in the agenda buffer with no context at all. IMO, a better rationale behind GUID is that headlines can change and thus not be reached anymore by a search string. Having a GUID would fix this. But I'm definitely not a GUID-fan, sorry :) -- 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
"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
"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
On 10/9/07, Bastien <[EMAIL PROTECTED]> wrote: > "Eddward DeVilla" <[EMAIL PROTECTED]> writes: > > 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)? I think so. It kinda clicked for me in the other thread. I'd probably use BLOCKER more myself, but I think I like the idea of using it with TRIGGER to have a high level task that is marked done or would depending on it's sub tasks. It would be like a todo item equivalent to the [/] & [%] tokens in plain lists. > > 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. That part of it is seems pretty simple and elegant. > Maybe this was just an over-reaction to the idea of GUID or labels, > which sounds like we are going into trouble. GUIDs did sound a little off for org. Labels would introduce a management /maintenance problem for the user. I felt I needed something to built my dependency relations with. It's hard to 'address' a todo item. Link's might be the best thing we have for that. 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. 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 10/9/07, Richard G Riley <[EMAIL PROTECTED]> wrote: > I'm interested in this. Why would an Org file with permissions like 700 > be any more virus friendly than an .emacs with the same permissions? Een > taking the windows case, a .emacs is executed each and every time, but > the org file only when loaded and acted upon. Perhaps it an over reaction on my part. I know the occasional org-file gets posted on this list. I'd like to see org catch on and see more info made available in org files. I don't normally send my .emacs file(s) to folks. That's my custom setup. (Though once in a while someone does copy it.) 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. So you have hidden code in a powerful language. It's not very hidden and I know it not likely that org's format would catch on the way I'd like. Anyhow, I'm not saying don't do it. I just wanted to be sure it wasn't overlooked. 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 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
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
"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
"Eddward DeVilla" <[EMAIL PROTECTED]> writes: > 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. Well, thinking of org-mode as a vector of trojan horse attacks sounds like science fiction to me :) Anyway, as I said, we could store the triggered actions in a pool and ask the user if he want to perform them. Of course the user would be allowed to turn a set of actions "safe" (see `safe-local-eval-forms') Not that a problem IMO. -- 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: > 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 I'm interested in this. Why would an Org file with permissions like 700 be any more virus friendly than an .emacs with the same permissions? Een taking the windows case, a .emacs is executed each and every time, but the org file only when loaded and acted upon. > > > ___ > 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
John Wiegley <[EMAIL PROTECTED]> writes: > Bastien <[EMAIL PROTECTED]> writes: > >> 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. > > How about just having generalized Lisp triggers: > > :PROPERTIES: > :TRIGGER: (lambda (previous new) >(if (string= (assoc "TODO" new) "DONE") >(org-find-and-schedule "regexp matching task" date))) > :END: > > In this example, previous and new are associative lists containing all of the > state information applicable to an entry. Yes, I like this very much. We could have both a TRIGGER and a BLOCKER property. The first one would trigger actions on tasks. The second one wouldn't let a change appear on the task unless some tasks are in a specific state. I tried to figure out how we could emulate the job of the BLOCKER property with only TRIGGER and an option like `org-check-triggers', saying that the action the TRIGGER is supposed to perform won't be allowed if it's not performed *by the TRIGGER* itself -- therefore enabling us to use "rigid" TRIGGERS and some kind of dependencies checks. But I don't think it's really feasible -- not even a good idea. > This kind of mechanism would allow Carsten to come up with a small > library of org-mode Lisp functions for programmatically manipulating > tasks simply by specifying a regular expression, or a relative offset, > to "locate" them. Yes, sounds like a good idea. > I would far prefer this to a specialized syntax, which in the end would > require so complexity as to become a domain-specific language in itself. I do agree the syntax I proposed was somewhat bloat. Consider it brain-dust after excitment! -- 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, Russell Adams <[EMAIL PROTECTED]> wrote: > On Mon, Oct 08, 2007 at 10:35:33PM -0500, Eddward DeVilla wrote: > > 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. That's what I did to. But my checkboxes lists had been very small steps. Projects were large collection of very small tasks. Dependencies weren't that complicated. The work I've moved into, projects don't have many steps, but there are many more projects in flight with a lot of dependencies, hard deadlines and starting a project can be gated by arrival of hardware, or availability of people who are too busy to write docs. In any case, that part of the beauty of org. It has several tools for organizing and tracking info. You can put them together in a lot of different and useful ways. The list of tools keep growing and Carsten does an excellent job of keeping things consistent, easy to use and independent. It's rare that you have to learn a multiple features just to use the one you want. Yet the all interact well. You can learn it a piece at a time. I've been dying to see dependency ordering added to that list. Sounds like there is some use for dependency based triggering. They both could be cool, but so far I'm not really attached to any of the suggested implementations yet. 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
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 10/8/07, Russell Adams <[EMAIL PROTECTED]> wrote: > I love this discussion on properties for dependencies, but does anyone > have a suggestion on how to visualize it? > > After you setup all these triggers, you still need a central place to > view the overview and steps involved (I'm thinking project management > specifically). I'm not even thinking triggers as much as seeing things marked Blocked if their dependencies are not met. > My most common use of org is project management, with one org file per > project, and there are always distinct phases for primary headers > (Client, Overview, Inventory, Implementation, Documentation, > Timecard). Often, the order subitems need to be accomplished in is > different than the order of the outline. 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. > Part of the original properties discussion revolved around project > management, dependencies, DURATION, and the ability to see a timeline > based on relative duration instead of schedule. > > Would an updated agenda view suffice? Would we need a way to link to > items and manually maintain order? Will our heros finally subdue the > evil Dr. Klan? Will the mysterious Gantt chart ever emerge? My wild imaginings were that it would develop into something providing the info for a gantt chart. More realistically, I was picturing a generated table of tasks sorted by dependencies, with estimated start and end dates filled in based on constrains imposed by dependency ordering, hard deadlines, hard set start dates, etc. Perhaps you could adjust ordering of task in the table when constrains allow it and get gripe messages or red flags in impossible situations. Perhaps it could color items that make up a critical path. It could be an agenda like view with remove editing features and highlighting effects, but I'm not sure that would be the best or most flexible design. Given properties and dynamic blocks, we have tools to implement something basic outside of org-mode now. Even a gantt chart generator. For me, it's a time thing. That and my work situation has changed dramatically and the way I planned work before does work well in my current situation. 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
Bastien <[EMAIL PROTECTED]> writes: > 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. How about just having generalized Lisp triggers: :PROPERTIES: :TRIGGER: (lambda (previous new) (if (string= (assoc "TODO" new) "DONE") (org-find-and-schedule "regexp matching task" date))) :END: In this example, previous and new are associative lists containing all of the state information applicable to an entry. This kind of mechanism would allow Carsten to come up with a small library of org-mode Lisp functions for programmatically manipulating tasks simply by specifying a regular expression, or a relative offset, to "locate" them. I would far prefer this to a specialized syntax, which in the end would require so complexity as to become a domain-specific language in itself. 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
I'm not sure we are talking about the same things really.
On 10/8/07, Bastien <[EMAIL PROTECTED]> wrote:
> "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.
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. 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.
The reasons for the dependencies could be anything. (Requires a
certain person's time, requires requisite info/result generated in
other/blocking steps, artistic flare) Given a set of such ordering
constraints, and estimated times to complete a step, what is the
soonest a step can be started or completed? Can I use this info to
generate a table of tasks with project start and end dates?
> > 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".
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.
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
Russell Adams <[EMAIL PROTECTED]> writes: > I love this discussion on properties for dependencies, but does anyone > have a suggestion on how to visualize it? Building a sparse tree with headlines that are affected by actions possibily triggered from the current task? > After you setup all these triggers, you still need a central place to > view the overview and steps involved (I'm thinking project management > specifically). Trying to figure this out will surely help designing the right implementation for task dependencies -- but maybe we've already speculated way too far and should refrain from getting the whole picture at once (I take responsability, if needed :) > Part of the original properties discussion revolved around project > management, dependencies, DURATION, and the ability to see a timeline > based on relative duration instead of schedule. Yes, I can remember that. Good old days. > Would an updated agenda view suffice? Would we need a way to link to > items and manually maintain order? Will our heros finally subdue the > evil Dr. Klan? Will the mysterious Gantt chart ever emerge? I guess most people in this list lost their jobs already anyway. -- 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
I love this discussion on properties for dependencies, but does anyone have a suggestion on how to visualize it? After you setup all these triggers, you still need a central place to view the overview and steps involved (I'm thinking project management specifically). My most common use of org is project management, with one org file per project, and there are always distinct phases for primary headers (Client, Overview, Inventory, Implementation, Documentation, Timecard). Often, the order subitems need to be accomplished in is different than the order of the outline. Part of the original properties discussion revolved around project management, dependencies, DURATION, and the ability to see a timeline based on relative duration instead of schedule. Would an updated agenda view suffice? Would we need a way to link to items and manually maintain order? Will our heros finally subdue the evil Dr. Klan? Will the mysterious Gantt chart ever emerge? Thanks! -- Russell Adams[EMAIL PROTECTED] PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint:1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3 signature.asc Description: Digital signature ___ 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:
> 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
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
Re: [Orgmode] depending TODOs, scheduling following TODOs automatically
On 10/8/07, Bastien <[EMAIL PROTECTED]> wrote:
> Implementing tasks-dependencies sounds pretty exciting!
>
> 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
> `
>
[:snip:]
> What do you think?
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. 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.
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 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.
___
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 09:48:28PM +0200, Carsten Dominik wrote: > > On Oct 8, 2007, at 15:52, Russell Adams wrote: > > >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 > > I don't know what others think, but I did not understand a single word > of this message :-) Could you please be a bit more verbose? > > - Carsten 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? ;] 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
Implementing tasks-dependencies sounds pretty exciting!
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?
--
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 15:52, Russell Adams wrote: 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 I don't know what others think, but I did not understand a single word of this message :-) Could you please be a bit more verbose? - Carsten 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 -- Carsten Dominik Sterrenkundig Instituut "Anton Pannekoek" Universiteit van Amsterdam Kruislaan 403 NL-1098SJ Amsterdam phone: +31 20 525 7477 ___ 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
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
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
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
[Orgmode] depending TODOs, scheduling following TODOs automatically
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. How do you folks handle such dependencies? Could any automatic process be implemented? * TODO job 1 SCHEDULED: <2007-10-12 Fr> * TODO job 2 (followup of job 1) * TODO job 3 (followup of job 2) rainer ___ 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
