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

[Martin Becker]

Hi again,

On 03.05.2013 22:25, Christian Egli wrote:
> 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.
Of course this rarely works out like that. At least me, I am using such 
planning to see "how wrong" I was and what is the impact of that. 
Though, "booking" would be better for that as I learned meanwhile.
> > > 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.
yes...see above.
>    
> > 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.
That's why I stopped the inferred progress at 99%...one never knows as 
the linked thread shows ;) Until there is a change in semantics for that 
property, it shouldn't hurt to guess it like that.
> > - 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.
Agreed, I think that's much more interesting than `complete'. However is 
tricky to integrate that well without ending in bad (ox-taskjuggler) 
user experience caused by TJ3 refusing to schedule...
> > 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.
I am not quiet through TJ3 doc to understand what projection really is, 
but it seems that booking only *some* tasks also makes a difference (as 
I said, it grows the effort if there was an underestimation and thereby 
affects the project timing). Eventually a user could clock and book just 
a subset of the tasks (e.g., his own) and skip others or whatever...
> > 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.
Will do.
> Thanks
> Christian

Thanks &
have a nice weekend,
Martin