From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christian Egli Subject: Re: [PATCH] Smart inference of task progress when exporting to TJ3 Date: Fri, 03 May 2013 22:25:11 +0200 Message-ID: <87txmjak0o.fsf@sbs.ch> References: <0LlWCR-1TzVer28MZ-00b7Lb@smtp.web.de> <87r4hobgna.fsf@tanger.home> <51839ED3.6070609@web.de> <87fvy4t81g.fsf@sbs.ch> <5183EE51.80000@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: Received: from eggs.gnu.org ([208.118.235.92]:48035) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYMXp-0002Jx-07 for emacs-orgmode@gnu.org; Fri, 03 May 2013 16:25:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UYMXn-00054Y-Q0 for emacs-orgmode@gnu.org; Fri, 03 May 2013 16:25:28 -0400 Received: from plane.gmane.org ([80.91.229.3]:60643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYMXn-00054P-Jf for emacs-orgmode@gnu.org; Fri, 03 May 2013 16:25:27 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1UYMXj-0005i3-Cz for emacs-orgmode@gnu.org; Fri, 03 May 2013 22:25:23 +0200 Received: from alouette.sbs.ch ([194.29.12.218]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 May 2013 22:25:23 +0200 Received: from christian.egli by alouette.sbs.ch with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 03 May 2013 22:25:23 +0200 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 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. >> 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