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
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
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 plann
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 a
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 ca
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 s
> "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 l
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
> "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
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. :-)
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]> wr
> "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 th
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 se
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 connect
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
> 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 disc
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
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 :ADDRESSTHI
"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 acc
"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
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
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 wh
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
* Implementati
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:
"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
"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 ficti
"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
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:
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 checkb
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 actua
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
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 pr
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
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
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
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
"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 'previ
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.
Up
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 'n
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
>
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 l
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
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 "
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 gi
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 t
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'
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 prece
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 (f
48 matches
Mail list logo
