From: Martin Becker <vbmazter@web.de>
To: emacs-orgmode@gnu.org
Subject: Re: [PATCH] Smart inference of task progress when exporting to TJ3
Date: Fri, 03 May 2013 19:05:21 +0200 [thread overview]
Message-ID: <5183EE51.80000@web.de> (raw)
In-Reply-To: <87fvy4t81g.fsf@sbs.ch>
[-- Attachment #1.1: Type: text/plain, Size: 2527 bytes --]
Hi Christian,
> I like this patch, this is good stuff. Can you tell me how you use
> this?
Thanks, I attached a file where I made some tests. 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.
> 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.
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". Being only "cosmetic", tracking can be done via clock times as
proposed.
- 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). 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? Additionally, the visually
attractive completeness is not derived from the bookings or anything.
> I would write this using cond instead of nested if. Makes it more
> clear.
Oh yes, I will do that. I am fairly new to Lisp, it is a nice exercise.
>>> 2. IIUC you don't need the TINYCHANGE cookie because the changes
>>> are made in contrib/ which doesn't require copyright assignment.
> The taskjuggler exporter used to be in core before it was moved to
> contrib by Bastien or Nicolas on the bases that there aren't many
> users (and probably because it wasn't maintained very well). This is
> OK for now, 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? That is not a problem, I happily
contribute here.
[-- Attachment #1.2: Type: text/html, Size: 3296 bytes --]
[-- Attachment #2: tj3test.org --]
[-- Type: text/plain, Size: 4070 bytes --]
#+PROPERTY: Effort_ALL 2d 5d 10d 20d 30d 35d 50d
#+PROPERTY: allocate_ALL dev doc test
#+PROPERTY: ORDERED_ALL true false
#+COLUMNS: %70ITEM(Task) %3Effort %8allocate %BLOCKER %ORDERED
* Resources :taskjuggler_resource:
** Developers
:PROPERTIES:
:resource_id: dev
:END:
*** Paul Smith
:PROPERTIES:
:resource_id: paul
:END:
*** Sébastien Bono
:PROPERTIES:
:resource_id: seb
:END:
*** Klaus Müller
** Others
*** Peter Murphy
:PROPERTIES:
:resource_id: doc
:limits: { dailymax 7h }
:END:
*** Dim Sung
:PROPERTIES:
:resource_id: test
:END:
* Accounting Software :taskjuggler_project:
SCHEDULED: <2013-04-15 Mo>
** STARTED Specification
- State "STARTED" from "TODO" [2013-05-02 Do 16:50]
CLOCK: [2013-04-30 Do 16:50]--[2013-05-03 Do 16:50] => 72:00
:PROPERTIES:
:Effort: 20d
:allocate: dev
:task_id: task_spec
:END:
** Software Development
:PROPERTIES:
:allocate: dev
:ORDERED: true
:BLOCKER: previous-sibling
:task_id: task_dev
:END:
*** TODO Database coupling
CLOCK: [2013-05-03 Do 15:21]--[2013-05-11 Do 22:21] => 199:00
:PROPERTIES:
:Effort: 20d
:END:
*This task uses the smart progress inference*: This task's
completeness is guessed using the clocked times, since it has no
explicit `complete' property. However the clock durations add up
to more than the effort and TJ3 does only allow values
[0,100]. Therefore semantically the task is not regarded as
complete until the TODO state equals "done", no matter how much we
clock on it. According to TJ3 doc, the complete information has
no impact on the TJ3 scheduler, it's pure documentation.
*Alternatives*:
1) Instead of setting `complete', we could set the property
`booking' for a resource or task, when we export to TJ3. Then
TJ3 would have additional information, since the bookings
reflect how much work was actually put into a task vs. how much
we originally planned. Note that unlike `complete' this has an
impact on the scheduling. TJ3 then can schedule a new plan
based on the amount of work that actually happened. Downside
is, that the org-syntax does not capture who/which resource
clocks on a task. And that the clock times will cause
scheduling errors when they do not comply with the scheduled
time windows for the tasks (e.g., when the bookings are earlier
than the task could have started, which can be constrained by
dependencies). When the bookings exceed the effort, TJ3 overwrites the effort with the booking value.
No completeness is calculated automatically though.
2) We continue to set `complete', but when the progress rendered
by the clocksum exceeds 100%, we adjust the effort s.t. it
yields 99% again. However, this might be surprising since the
export shows different efforts than the org-file.
*** Back-End Functions
:PROPERTIES:
:Effort: 5d
:task_id: task_backend
:END:
*** Graphical User Interface
:PROPERTIES:
:Effort: 35d
:END:
** Software testing
:PROPERTIES:
:allocate: test, paul
:ORDERED: true
:BLOCKER: task_dev
:END:
*** Alpha Test
:PROPERTIES:
:Effort: 5d
:task_id: task_alpha
:END:
*** Beta Test
:PROPERTIES:
:Effort: 20d
:allocate: test
:task_id: task_beta
:END:
** Manual
CLOCK: [2013-05-03 Fr 12:48]--[2013-05-08 Fr 17:48] => 125:00
:PROPERTIES:
:Effort: 50d
:allocate: doc
:BLOCKER: task_spec
:complete: 75
:task_id: task_manual
:END:
This task's completeness is explicitly set. Even if there are
clock in this task, it is being ignored.
** Milestones
*** Project start
*** Technology Preview
:PROPERTIES:
:BLOCKER: task_backend
:END:
*** Beta version
:PROPERTIES:
:BLOCKER: task_alpha
:END:
*** Ship Product to Customer
:PROPERTIES:
:BLOCKER: task_beta task_manual
:END:
next prev parent reply other threads:[~2013-05-03 17:05 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 [this message]
2013-05-03 20:25 ` Christian Egli
2013-05-03 23:06 ` Martin Becker
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=5183EE51.80000@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).