From: Martin Becker <vbmazter@web.de>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Smart inference of task progress when exporting to TJ3
Date: Sat, 04 May 2013 01:06:22 +0200 [thread overview]
Message-ID: <518442EE.2030604@web.de> (raw)
In-Reply-To: <87txmjak0o.fsf@sbs.ch>
Hi again,
On 03.05.2013 22:25, Christian Egli wrote:
> 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.
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
next prev parent reply other threads:[~2013-05-03 23:06 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
2013-05-03 23:06 ` Martin Becker [this message]
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=518442EE.2030604@web.de \
--to=vbmazter@web.de \
--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).