emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [PATCH] Smart inference of task progress when exporting to TJ3


From: Christian Egli
Subject: Re: [O] [PATCH] Smart inference of task progress when exporting to TJ3
Date: Fri, 03 May 2013 22:25:11 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

Hi Martin

Martin Becker <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]