Duration Tally

Duration Tally

[Russell Adams]

If this feature already exists, I've missed it...

I'm planning ahead on some items, and having a way to represent the
amount of time a TODO item will take, and then having the parent total
the duration of the children would be very helpful.

* TODO A {6h}
** TODO a1 {2h}
** TODO a2 {2h}
** TODO a3 {2h}

I know doing time conversion is a real pain, so I'm only thinking a
simple sum. It could be nice later to schedule A, and then have each
of a1-3 show up on the agenda based on their duration.

Kudos again on Org-mode, its great!

Thanks!

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Duration Tally

[Eddward DeVilla]

    I'm starting to wonder if it would be useful to have a general
format for properties (or choose some other word) to be associated
with a heading or todo item.  It seems the heading is getting a little
crowded.

    Would it be reasonable to say that a list of non-whitespace
listing following the heading with a format of "key: value..." are
special.  (Or a table might be nice.  I like tables.:)  org-mode could
provide an interface to get a plist or alist of them for a heading to
simplify writing now features based on them.

    We already have SCHEDULED, DEADLINE, & CLOSED that are meaningful
to org-mode.  This request reminds me of one use call estimate.  These
properties could then be made available in agenda for custom queries
and displays.

   This may not meet your requirement since I'm guessing you would
want the value in the heading so you can see it.  You idea just
inspired me to ask.  My idea wouldn't do the totaling, but I think it
could be the start to allow some similar but more generalized.  I
don't know of anything in org-mode that does what you ask right now.
I would think there would need to be to tokens.  One that is 'this'
heading's value and a second one that is 'this' heading's value, plus
its children's.  It would be like the checkboxes and the progress
tokens.

Edd

Edd

On 6/13/07, Russell Adams <RLAdams@adamsinfoserv.com> wrote:
> If this feature already exists, I've missed it...
>
> I'm planning ahead on some items, and having a way to represent the
> amount of time a TODO item will take, and then having the parent total
> the duration of the children would be very helpful.
>
> * TODO A {6h}
> ** TODO a1 {2h}
> ** TODO a2 {2h}
> ** TODO a3 {2h}
>
> I know doing time conversion is a real pain, so I'm only thinking a
> simple sum. It could be nice later to schedule A, and then have each
> of a1-3 show up on the agenda based on their duration.
>
> Kudos again on Org-mode, its great!
>
> Thanks!
>
> ------------------------------------------------------------------
> Russell Adams                            RLAdams@AdamsInfoServ.com
>
> PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/
>
> Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
>
>
> _______________________________________________
> Emacs-orgmode mailing list
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
>

Re: Duration Tally

[Russell Adams]

I like that alot!

However my goal was one of simple project planning.

Thanks!

On Wed, Jun 13, 2007 at 10:33:48AM -0500, Eddward DeVilla wrote:
>    I'm starting to wonder if it would be useful to have a general
> format for properties (or choose some other word) to be associated
> with a heading or todo item.  It seems the heading is getting a little
> crowded.
> 
>    Would it be reasonable to say that a list of non-whitespace
> listing following the heading with a format of "key: value..." are
> special.  (Or a table might be nice.  I like tables.:)  org-mode could
> provide an interface to get a plist or alist of them for a heading to
> simplify writing now features based on them.
> 
>    We already have SCHEDULED, DEADLINE, & CLOSED that are meaningful
> to org-mode.  This request reminds me of one use call estimate.  These
> properties could then be made available in agenda for custom queries
> and displays.
> 
>   This may not meet your requirement since I'm guessing you would
> want the value in the heading so you can see it.  You idea just
> inspired me to ask.  My idea wouldn't do the totaling, but I think it
> could be the start to allow some similar but more generalized.  I
> don't know of anything in org-mode that does what you ask right now.
> I would think there would need to be to tokens.  One that is 'this'
> heading's value and a second one that is 'this' heading's value, plus
> its children's.  It would be like the checkboxes and the progress
> tokens.
> 
> Edd
> 
> Edd
> 
> On 6/13/07, Russell Adams <RLAdams@adamsinfoserv.com> wrote:
> >If this feature already exists, I've missed it...
> >
> >I'm planning ahead on some items, and having a way to represent the
> >amount of time a TODO item will take, and then having the parent total
> >the duration of the children would be very helpful.
> >
> >* TODO A {6h}
> >** TODO a1 {2h}
> >** TODO a2 {2h}
> >** TODO a3 {2h}
> >
> >I know doing time conversion is a real pain, so I'm only thinking a
> >simple sum. It could be nice later to schedule A, and then have each
> >of a1-3 show up on the agenda based on their duration.
> >
> >Kudos again on Org-mode, its great!
> >
> >Thanks!
> >
> >------------------------------------------------------------------
> >Russell Adams                            RLAdams@AdamsInfoServ.com
> >
> >PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/
> >
> >Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3
> >
> >
> >_______________________________________________
> >Emacs-orgmode mailing list
> >Emacs-orgmode@gnu.org
> >http://lists.gnu.org/mailman/listinfo/emacs-orgmode
> >
> 
> 
> _______________________________________________
> Emacs-orgmode mailing list
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Duration Tally

[Jason F. McBrayer]

"Eddward DeVilla" <eddward@gmail.com> writes:

>    We already have SCHEDULED, DEADLINE, & CLOSED that are meaningful
> to org-mode.

And CLOCK, as well.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray@carcosa.net  |
| 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    |

Re: Duration Tally

[Carsten Dominik]

On Jun 13, 2007, at 17:33, Eddward DeVilla wrote:

>    I'm starting to wonder if it would be useful to have a general
> format for properties (or choose some other word) to be associated
> with a heading or todo item.  It seems the heading is getting a little
> crowded.
>
>    Would it be reasonable to say that a list of non-whitespace
> listing following the heading with a format of "key: value..." are
> special.  (Or a table might be nice.  I like tables.:)  org-mode could
> provide an interface to get a plist or alist of them for a heading to
> simplify writing now features based on them.

One of the advantages of using plain text for notes files like
we do with Org-mode is, that you can of course implement any system
you like to store additional information.  Keyword lists, tables,
anything.

So the discussion must be about how you would like Org-mode to make
use of such data.  Obviously it would be easy to write (as you
suggest) a little function that returns all this data as, say,
a property list.  But then you would still need to use it in
some way.  Are you suggesting tis as a feature where some users
(those who can write Lisp code) write their own extensions?
That is certainly an option.  Are you also envisioning ways
how Org-mode should use this?

Here are tow ideas:

- a LOCATION keyword would be useful for exporting to iCalendar,
   this was already proposed by Bastien a while ago.

- We could allow the TAGS match to set conditions based on these
   keywords.  Right now, a tags match can say "LEVEL=2" to require
   entries with putline level 2.  In a similar way one could allow
   "LOCATION=Paris" or whatever, that would be something quite
   easily implemented.

Nothing of this will be in todays release, obviously, this needs
more careful thinking.  Thanks for starting this discussion.

- Carsten

Re: Duration Tally

[Russell Adams]

> So the discussion must be about how you would like Org-mode to make
> use of such data.  Obviously it would be easy to write (as you
> suggest) a little function that returns all this data as, say,
> a property list.  But then you would still need to use it in
> some way.  Are you suggesting tis as a feature where some users
> (those who can write Lisp code) write their own extensions?
> That is certainly an option.  Are you also envisioning ways
> how Org-mode should use this?
> 

I'm not afraid of coding, I'll just have to pick up lisp. ;]

The idea of the key/value pairs simply means that custom features can
be implemented at any time without changing the core org-mode.

I do like the idea of doing simple searches on the key/value pairs, I
also like the thought of another level of folding. If you have 5
extra lines of k/v pairs under a heading, maybe you don't want to see
them all unless you ask.

The original submitter had the right idea, this allows alot of
expansion and customization with minimal overhead.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Duration Tally

[Eddward DeVilla]

On 6/19/07, Carsten Dominik <dominik@science.uva.nl> wrote:
>
> On Jun 13, 2007, at 17:33, Eddward DeVilla wrote:
>
> >    I'm starting to wonder if it would be useful to have a general
> > format for properties (or choose some other word) to be associated
> > with a heading or todo item.  It seems the heading is getting a little
> > crowded.
> >
> >    Would it be reasonable to say that a list of non-whitespace
> > listing following the heading with a format of "key: value..." are
> > special.  (Or a table might be nice.  I like tables.:)  org-mode could
> > provide an interface to get a plist or alist of them for a heading to
> > simplify writing now features based on them.
>
> One of the advantages of using plain text for notes files like
> we do with Org-mode is, that you can of course implement any system
> you like to store additional information.  Keyword lists, tables,
> anything.
>
> So the discussion must be about how you would like Org-mode to make
> use of such data.  Obviously it would be easy to write (as you
> suggest) a little function that returns all this data as, say,
> a property list.  But then you would still need to use it in
> some way.  Are you suggesting tis as a feature where some users
> (those who can write Lisp code) write their own extensions?
> That is certainly an option.  Are you also envisioning ways
> how Org-mode should use this?
>
> Here are tow ideas:
>
> - a LOCATION keyword would be useful for exporting to iCalendar,
>    this was already proposed by Bastien a while ago.
>
> - We could allow the TAGS match to set conditions based on these
>    keywords.  Right now, a tags match can say "LEVEL=2" to require
>    entries with putline level 2.  In a similar way one could allow
>    "LOCATION=Paris" or whatever, that would be something quite
>    easily implemented.
>
> Nothing of this will be in todays release, obviously, this needs
> more careful thinking.  Thanks for starting this discussion.

    I don't expect to see any of this soon or in this form.  It just
idea I've been trying to justify bringing up.  Where I'd want to use
it most is in custom agenda queries.  "Show me projects(todos) that
are associated with release X of product Y.  Release and Product would
be my keywords.
    Right now all we have is a TODO state and a list of tags.  Tags
are basically boolean.  You have to have a tag for each thing you want
to report on.  A tag for every product ID, a tag for every release
identifier, tags for interested parties, tags for classes, etc.  And
all the tags are mixed together in a long run-on string at the end of
the heading.  It can get unreadable.

    I also would like to be able to set a property like this that I
can then use in tables under the TODO item.  I'd have other uses for
that, but I'd like to set the property in the same way.  This isn't as
useful, but I've wished for it more than once.  Just a way to set a
variable in an org document that I can then use in formula.
Originally I thought it would be a '#' directive but I do like this as
a possible way to do it.

    While playing with these ideas and reading the message that
trigger all of this, I thought it would be nice to be able to code an
extension that would allow me to insert a keyword like TOTAL_DURATION:
that would automatically (based on some trigger) be assigned a value
equal to the sum of all the DURATION: values under the current TODO
item.  I know the original request sounded useful, but it seem very
non-general and it was yet another thing to clutter the heading.
    The property list would give us easy access to user/plugin
definable/managed fields.  I think we would want a way to hook into a
few other org-isms, like having an easy way to say C-cC-c or C-uC-cC-c
makes something happen here.  But this is all still wild fantasy of
the bizarre and possibly impractical.  I was hoping it might bring
about a better idea.

Edd

Re: Duration Tally

[Scott Jaderholm]

On 6/19/07, Carsten Dominik <dominik@science.uva.nl> wrote:

> So the discussion must be about how you would like Org-mode to make
> use of such data.  Obviously it would be easy to write (as you
> suggest) a little function that returns all this data as, say,
> a property list.  But then you would still need to use it in
> some way.  Are you suggesting tis as a feature where some users
> (those who can write Lisp code) write their own extensions?
> That is certainly an option.  Are you also envisioning ways
> how Org-mode should use this?

I see a property list under each heading as a way of doing columns,
albeit in a less user friendly way. I can see this being useful
anywhere you have hierarchal data to which you would like to add
structure. Currently, I normally transfer it into a table, but it
would be nice to be able to leave things as a list and still define
some columns. See
http://www.omnigroup.com/images/applications/omnioutliner/features/multicolumn.jpg

Perhaps a property list has the advantage of being easier for the
programmers and being a better way to store the data in a text file,
but I think it would be really sweet if an interface were built on top
of it so that the user saw something similar to the picture above.

Carsten,
Have spreadsheet like columns for lists been discussed before, and if
so, what was the verdict?

--Scott

Re: Duration Tally

[Eddward DeVilla]

On 6/19/07, Scott Jaderholm <jaderholm@gmail.com> wrote:
> I see a property list under each heading as a way of doing columns,
> albeit in a less user friendly way. I can see this being useful
> anywhere you have hierarchal data to which you would like to add
> structure. Currently, I normally transfer it into a table, but it
> would be nice to be able to leave things as a list and still define
> some columns. See
> http://www.omnigroup.com/images/applications/omnioutliner/features/multicolumn.jpg
>
> Perhaps a property list has the advantage of being easier for the
> programmers and being a better way to store the data in a text file,
> but I think it would be really sweet if an interface were built on top
> of it so that the user saw something similar to the picture above.

Seems to me you could have an agenda-like view where you give a
selection criteria and a list of fields to display.  I guess you could
wrap it in a table if you like.  At this point we'd have invented SQL
queries for org-mode.  I can't decide yet if I think it's overkill or
cool.  It seemed cool until I realized it was functionally just a
select-where statement.  But that is really all I was after. Dynamic
reports from all my org-files.

Edd

Re: Duration Tally

[Carsten Dominik]

On Jun 19, 2007, at 19:45, Scott Jaderholm wrote:
>
> Carsten,
> Have spreadsheet like columns for lists been discussed before, and if
> so, what was the verdict?

I have seen them mentioned before but never understood
what was meant, so nothing from my side happened.  Thanks
for sending the illustration from omni-outliner, so at
least I have now an idea what this is about.

What I find a bit strange though is that it is using a hierarchy,
and every level of the hierarchy has the same columns.  Columns
seem to make more sense for items with equal level, at least to me.

- Carsten

Re: Duration Tally

[Scott Jaderholm]

On 6/22/07, Carsten Dominik <dominik@science.uva.nl> wrote:

> What I find a bit strange though is that it is using a hierarchy,
> and every level of the hierarchy has the same columns.  Columns
> seem to make more sense for items with equal level, at least to me.

I think it's harder to design an interface where different levels have
different columns.

Sometimes the columns will make sense on different levels so they opt
to leave them there. Also, as we see in the screenshot, they can be
used for summaries of almost anything that can be summed.

A simple example where columns apply to different levels, other than
summaries, is this:

* Saturday Projects                    (In charge)
** TODO Clean yard                   Bobby
*** TODO Rake                          Sue
*** TODO Mow lawn                   John

One thing I forgot to mention that I like about organizing information
in trees with columns instead of tables is the flexibility in storing
notes.

* People		(Phone Number)
** Family
*** Ben			123-123-1234				       :soccer:
    I can have information about Ben down here under his name
    that isn't necessarily organized in a structured manner. This could
    be notes or brainstorming or other things.
    - I can paste content from elsewhere here and mostly retain formatting
    - it can have newlines
    - it won't be visible in a summary
    - I can use bulleted lists
    - I don't have to type Family every time I add an entry
    - I can cycle visibility
** Friends
*** John		123-123-1235
** Work					(Employee #)
*** Steve				1

An equivalent table would look like:
| Category | Name  |        Phone | Employee # | Notes
                                                            |
|----------+-------+--------------+------------+-----------------------------------------------------------------------------------|
| Family   | Ben   | 123-123-1234 |            | I have to create a
separate column here for notes, and it won't let me have new lines |
| Friends  | John  | 123-123-1235 |            |
                                                            |
| Work     | Steve |              |          4321 |
                                                               |

If org ever gets columns, I would hope that they could be defined on a
level smaller than for the entire file.

I guess I've shown that it is possible to do basic columns right now,
it just involves a lot of M-i and isn't very pretty. I can only
imagine how much work a real columns implementation would take.

Cheers,
Scott

Re: Duration Tally

[Eddward DeVilla]

On 6/22/07, Scott Jaderholm <jaderholm@gmail.com> wrote:
> I think it's harder to design an interface where different levels have
> different columns.
>
> Sometimes the columns will make sense on different levels so they opt
> to leave them there. Also, as we see in the screenshot, they can be
> used for summaries of almost anything that can be summed.
>
> A simple example where columns apply to different levels, other than
> summaries, is this:
>
> * Saturday Projects                    (In charge)
> ** TODO Clean yard                   Bobby
> *** TODO Rake                          Sue
> *** TODO Mow lawn                   John

Seems to me that columns, here, are just a summary of things that are
attached (or that you wished were attached) to the heading with
alignment thrown in.  It sort of seems to me what the agenda buffer is
for.  Maybe it an agenda query with the ability to 'unfold' the
heading in place in the agenda buffer.

> One thing I forgot to mention that I like about organizing information
> in trees with columns instead of tables is the flexibility in storing
> notes.

I know on more than one occasion I've wanted to be able to fold a
sub-section of a table.  Just to be able to put a '-' in front of the
portions of the table I'd like to group and be able to fold and still
keep it one table.  That's not quite what you are asking for here, but
I think it could be made related.  I'm not sure how to implement a
hierarchy in a visually pleasing way.

I think the idea of having an org-table with foldable inline notes
would be useful too.  Say if the line (or lines) following a table row
starts with a '!' (or some other character, I was thinking ':' but
that already has a meaning) then it is a note attached to that row.
You could have a binding to toggle the visibility for a row or for the
table.  I don't know what key to use since tab already has a good use
in tables.

Also, there the question of whether the prefix character is desirable
since it would get in the way of using lists and headings as notes for
the row.  We could just say we don't do that, but it could be nice if
it were allowed.  I don't know how you would be able to tell one table
from the next though.

Maybe we say that if the first character of a heading is a '|' it is
part of a heading-table?  Again, I don't know how to make it look nice
or behave with todo keywords.

Edd

Re: Duration Tally

[Scott Jaderholm]

On 6/13/07, Russell Adams <RLAdams@adamsinfoserv.com> wrote:

> I'm planning ahead on some items, and having a way to represent the
> amount of time a TODO item will take

On a similar note, I like using the clocktable to see how long things
have taken me, but sometimes I just want to put a time value under a
heading, not a time range (because I forgot to clock in/out). Could
CLOCK: => 2:00 or something similar work? If it did, maybe this could
work for Russell as well (if he didn't mind using a clocktable instead
of seeing it in the headline).

Btw, I like Eddward's idea. Two other candidates for the property
list/table are status (TODO, DONE) and tags. It might be more work
however refactoring all the code that uses/displays them than the
consistency would be worth.

--Scott

Fwd: Duration Tally

[Eddward DeVilla]

Just forwarding to the list.  I forgot to.

---------- Forwarded message ----------
From: Eddward DeVilla <eddward@gmail.com>
Date: Jun 13, 2007 8:37 PM
Subject: Re: [Orgmode] Duration Tally
To: Scott Jaderholm <jaderholm@gmail.com>


On 6/13/07, Scott Jaderholm <jaderholm@gmail.com> wrote:
> On 6/13/07, Russell Adams <RLAdams@adamsinfoserv.com> wrote:
>
> > I'm planning ahead on some items, and having a way to represent the
> > amount of time a TODO item will take
>
> On a similar note, I like using the clocktable to see how long things
> have taken me, but sometimes I just want to put a time value under a
> heading, not a time range (because I forgot to clock in/out). Could
> CLOCK: => 2:00 or something similar work? If it did, maybe this could
> work for Russell as well (if he didn't mind using a clocktable instead
> of seeing it in the headline).
>
> Btw, I like Eddward's idea. Two other candidates for the property
> list/table are status (TODO, DONE) and tags. It might be more work
> however refactoring all the code that uses/displays them than the
> consistency would be worth.
>
> --Scott

Well, I wouldn't want too go to far in changing/breaking things.  I
just know that some things matter to me, but they might not matter to
enough others to build it into org.  Tags and todo sequences are
pretty general in themselves and it make sense for them to be treated
special bu org and agenda.  Also, all of this hinges on it not being
too unreasonable to fit into org-mode.  I just figured that attaching
an easy to access list of key value pairs that can be filtered on and
use in calculations might be generally useful.  I was just trying to
expand on the schedule keywords.

I haven't use clock table yet so I can't really comment on that.  I
was going to try to use deadlines, estimates and dependencies on todos
to build something like a gant chart or milestone table.

Edd

Re: Duration Tally

[Carsten Dominik]

On Jun 13, 2007, at 23:58, Scott Jaderholm wrote:

> On 6/13/07, Russell Adams <RLAdams@adamsinfoserv.com> wrote:
>
>> I'm planning ahead on some items, and having a way to represent the
>> amount of time a TODO item will take
>
> On a similar note, I like using the clocktable to see how long things
> have taken me, but sometimes I just want to put a time value under a
> heading, not a time range (because I forgot to clock in/out). Could
> CLOCK: => 2:00 or something similar work? If it did, maybe this could
> work for Russell as well (if he didn't mind using a clocktable instead
> of seeing it in the headline).

This one is definitely useful, so it is on the TODO list.

- Carsten

Re: Duration Tally

[Russell Adams]

I'm looking specificaly at project planning...

I like the idea of the key/value pairs under a heading, perhaps later
it could be used for other datatypes (TID,DEPENDS,ASSIGNED, etc).

I frequently use a tree of TODO's to describe steps in a project plan,
and check them off as they are completed. 


On Fri, Jun 15, 2007 at 08:21:22AM +0200, Carsten Dominik wrote:
> 
> On Jun 13, 2007, at 23:58, Scott Jaderholm wrote:
> 
> >On 6/13/07, Russell Adams <RLAdams@adamsinfoserv.com> wrote:
> >
> >>I'm planning ahead on some items, and having a way to represent the
> >>amount of time a TODO item will take
> >
> >On a similar note, I like using the clocktable to see how long things
> >have taken me, but sometimes I just want to put a time value under a
> >heading, not a time range (because I forgot to clock in/out). Could
> >CLOCK: => 2:00 or something similar work? If it did, maybe this could
> >work for Russell as well (if he didn't mind using a clocktable instead
> >of seeing it in the headline).
> 
> This one is definitely useful, so it is on the TODO list.
> 
> - Carsten
> 
> 
> 
> _______________________________________________
> Emacs-orgmode mailing list
> Emacs-orgmode@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode
------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Duration Tally

[Carsten Dominik]

On Jun 13, 2007, at 15:47, Russell Adams wrote:

> If this feature already exists, I've missed it...
>
> I'm planning ahead on some items, and having a way to represent the
> amount of time a TODO item will take, and then having the parent total
> the duration of the children would be very helpful.
>
> * TODO A {6h}
> ** TODO a1 {2h}
> ** TODO a2 {2h}
> ** TODO a3 {2h}
>
> I know doing time conversion is a real pain, so I'm only thinking a
> simple sum.

This would be something like a hierarchical computation tool.
This is interesting, but the restriction to planned ours
may be a bit too narrow.

> It could be nice later to schedule A, and then have each
> of a1-3 show up on the agenda based on their duration.

I am not sure if I understand what you mean here.

- Carsten

Re: Duration Tally

[Russell Adams]

> >It could be nice later to schedule A, and then have each
> >of a1-3 show up on the agenda based on their duration.
> 
> I am not sure if I understand what you mean here.
> 
> - Carsten

I mean that the parent would be scheduled at a fixed date/time, and
then child entries would be in the agenda based on their relative
duration. That way you don't assign a fixed date/time to every entry,
just the first, and then manage by duration from there.




------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3

Re: Duration Tally

[Carsten Dominik]

On Jun 19, 2007, at 13:21, Russell Adams wrote:

>>> It could be nice later to schedule A, and then have each
>>> of a1-3 show up on the agenda based on their duration.
>>
>> I am not sure if I understand what you mean here.
>>
>> - Carsten
>
> I mean that the parent would be scheduled at a fixed date/time, and
> then child entries would be in the agenda based on their relative
> duration. That way you don't assign a fixed date/time to every entry,
> just the first, and then manage by duration from there.

You mean if I schedule the project on the 15th, and the first subtask
takes 8 hours, the second subtask should then be scheduled on the 16th?

- Carsten

Re: Duration Tally

[Russell Adams]

> takes 8 hours, the second subtask should then be scheduled on the 16th?
> 
> - Carsten

I hadn't considered using "workhours" logic, simply a relative time
forward from the schedule parent.

------------------------------------------------------------------
Russell Adams                            RLAdams@AdamsInfoServ.com

PGP Key ID:     0x1160DCB3           http://www.adamsinfoserv.com/

Fingerprint:    1723 D8CA 4280 1EC9 557F  66E8 1154 E018 1160 DCB3