From: Christian Egli <christian.egli@sbs.ch>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Smart inference of task progress when exporting to TJ3
Date: Fri, 03 May 2013 22:25:11 +0200 [thread overview]
Message-ID: <87txmjak0o.fsf@sbs.ch> (raw)
In-Reply-To: 5183EE51.80000@web.de
Hi Martin
Martin Becker <vbmazter@web.de> writes:
> My idea was, that clock times are only used when there is no explicit
> information given, viz., when there is neither a property `complete'
> nor the task state equals "done". Since I am clocking most of my
> activities, it would be convenient for me to let the exporter/TJ3
> infer the task progress instead of explicitly giving the `complete'
> property. So far for the story.
Ah, I get it. You are infering the % complete based on how much effort
you have already put into a task. The problem is that this doesn't
always relate to each other: You might have put a lot of effort into a
task and still be only at 10% complete.
>> I.e. does tj3 adapt the length fo a task based on your clock
>> table?
> No, TJ3 is not adapting anything here, neither am I. Since you cannot
> give values > 100 (%), my patch limits the maximum inferred progress
> to 99. We could let the exporter overwrite the effort with the
> clocksum in those cases, but it doesn't seem right.
Yes, since this is another problem with infering the complete
information from the planed effort and actual effort: You can end up
with complete more than 100% :-), namely if the actual effort is bigger
than the planed effort.
> I found out some more details after reading the documentation of TJ3:
> - The `complete' property is merely for documentation purposes, it's
> totally ignored by TJ3 when it comes to scheduling. It just "looks
> nice".
Yes, I think there are some other draw backs with the complete
information. Check the taskjuggler mailing list archives for a
discussion on tracking the progress of a project
(https://groups.google.com/d/topic/taskjuggler-users/ZCk_est4GKE/discussion).
I for one would like it if were used for scheduling.
> - But there is another thing we could do: One can add "bookings" to
> the tasks, which could be exactly the clock times from org-mode. I
> tried this manually and it seems to be a mixed blessing: If doing so,
> TJ3 internally grows the effort when the bookings exceed them and
> reschedules accordingly (which is nice).
This is something that would make sense in the exporter. The clocking
information that we have in the org file is really what tj3 wants as a
booking.
> On the other hand sensible clock times are vital then. What I mean is,
> when there are bookings that are too early w.r.t. a task's earliest
> possible start (due to dependencies etc.), then TJ3 exits with an
> error. I am not sure this is wanted behavior. What do you think?
Yes, it appears that you will have to have bookings for all the tasks to
make this work properly. This is a lot of overhead. I'm also not sure
this is wanted. But the benefit would be that you can use projection
mode in which tj3 will afaik recalculate the duration of the project
based an planed and actual effort. Might be worth exploring.
> Additionally, the visually attractive completeness is not derived from
> the bookings or anything.
Yes.
>> but eventually I'd like to move it back to core. So we need
>> assignment for this patch.
> Is it that I need to sign something?
Have a look at request-assign-future.txt in the org-mode git repo.
Thanks
Christian
--
Christian Egli
Swiss Library for the Blind, Visually Impaired and Print Disabled
Grubenstrasse 12, CH-8045 Zürich, Switzerland
next prev parent reply other threads:[~2013-05-03 20:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-02 21:24 [PATCH] Smart inference of task progress when exporting to TJ3 Martin
2013-05-03 8:40 ` Daimrod
2013-05-03 11:26 ` Martin Becker
2013-05-03 15:08 ` Christian Egli
2013-05-03 17:05 ` Martin Becker
2013-05-03 20:25 ` Christian Egli [this message]
2013-05-03 23:06 ` Martin Becker
2013-05-07 10:08 ` Bastien
2013-05-07 10:57 ` Bastien
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87txmjak0o.fsf@sbs.ch \
--to=christian.egli@sbs.ch \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).