From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Becker Subject: Re: [PATCH] Smart inference of task progress when exporting to TJ3 Date: Sat, 04 May 2013 01:06:22 +0200 Message-ID: <518442EE.2030604@web.de> References: <0LlWCR-1TzVer28MZ-00b7Lb@smtp.web.de> <87r4hobgna.fsf@tanger.home> <51839ED3.6070609@web.de> <87fvy4t81g.fsf@sbs.ch> <5183EE51.80000@web.de> <87txmjak0o.fsf@sbs.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:54335) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYP3f-0001fl-JS for emacs-orgmode@gnu.org; Fri, 03 May 2013 19:06:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UYP3b-0005wU-9u for emacs-orgmode@gnu.org; Fri, 03 May 2013 19:06:31 -0400 Received: from mout.web.de ([212.227.15.4]:57485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYP3a-0005wF-W3 for emacs-orgmode@gnu.org; Fri, 03 May 2013 19:06:27 -0400 Received: from [192.168.178.4] ([217.189.234.86]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0MYf78-1V3jP90Ify-00UphG for ; Sat, 04 May 2013 01:06:25 +0200 In-Reply-To: <87txmjak0o.fsf@sbs.ch> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: emacs-orgmode@gnu.org Hi again, On 03.05.2013 22:25, Christian Egli wrote: > Hi Martin > > Martin Becker 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