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: Fri, 03 May 2013 19:05:21 +0200 Message-ID: <5183EE51.80000@web.de> References: <0LlWCR-1TzVer28MZ-00b7Lb@smtp.web.de> <87r4hobgna.fsf@tanger.home> <51839ED3.6070609@web.de> <87fvy4t81g.fsf@sbs.ch> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------070300000207080009000106" Return-path: Received: from eggs.gnu.org ([208.118.235.92]:59153) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYJQH-0005xT-LC for emacs-orgmode@gnu.org; Fri, 03 May 2013 13:05:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UYJQC-0001Lp-Iu for emacs-orgmode@gnu.org; Fri, 03 May 2013 13:05:29 -0400 Received: from mout.web.de ([212.227.15.3]:54867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UYJQC-0001LX-Aa for emacs-orgmode@gnu.org; Fri, 03 May 2013 13:05:24 -0400 Received: from [192.168.178.4] ([217.189.234.86]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0MMn1H-1UfBqG0Ir1-0082tR for ; Fri, 03 May 2013 19:05:23 +0200 In-Reply-To: <87fvy4t81g.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 This is a multi-part message in MIME format. --------------070300000207080009000106 Content-Type: multipart/alternative; boundary="------------090809080104010009000107" --------------090809080104010009000107 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. --------------090809080104010009000107 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit 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.

--------------090809080104010009000107-- --------------070300000207080009000106 Content-Type: text/plain; charset=UTF-8; name="tj3test.org" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tj3test.org" IytQUk9QRVJUWTogRWZmb3J0X0FMTCAyZCA1ZCAxMGQgMjBkIDMwZCAzNWQgNTBkCiMrUFJP UEVSVFk6IGFsbG9jYXRlX0FMTCBkZXYgZG9jIHRlc3QKIytQUk9QRVJUWTogT1JERVJFRF9B TEwgdHJ1ZSBmYWxzZQojK0NPTFVNTlM6ICU3MElURU0oVGFzaykgJTNFZmZvcnQgJThhbGxv Y2F0ZSAlQkxPQ0tFUiAlT1JERVJFRAoKKiBSZXNvdXJjZXMgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDp0YXNranVnZ2xlcl9yZXNvdXJjZToKKiogRGV2 ZWxvcGVycwo6UFJPUEVSVElFUzoKOnJlc291cmNlX2lkOiBkZXYKOkVORDoKKioqIFBhdWwg U21pdGgKOlBST1BFUlRJRVM6CjpyZXNvdXJjZV9pZDogcGF1bAo6RU5EOgoqKiogU8OpYmFz dGllbiBCb25vCjpQUk9QRVJUSUVTOgo6cmVzb3VyY2VfaWQ6IHNlYgo6RU5EOgoqKiogS2xh dXMgTcO8bGxlcgoqKiBPdGhlcnMKKioqIFBldGVyIE11cnBoeQo6UFJPUEVSVElFUzoKOnJl c291cmNlX2lkOiBkb2MKOmxpbWl0czogICB7IGRhaWx5bWF4IDdoIH0KOkVORDoKKioqIERp bSBTdW5nCjpQUk9QRVJUSUVTOgo6cmVzb3VyY2VfaWQ6IHRlc3QKOkVORDoKCgoqIEFjY291 bnRpbmcgU29mdHdhcmUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDp0YXNr anVnZ2xlcl9wcm9qZWN0OgogIFNDSEVEVUxFRDogPDIwMTMtMDQtMTUgTW8+CioqIFNUQVJU RUQgU3BlY2lmaWNhdGlvbgogICAtIFN0YXRlICJTVEFSVEVEIiAgICBmcm9tICJUT0RPIiAg ICAgICBbMjAxMy0wNS0wMiBEbyAxNjo1MF0KICAgQ0xPQ0s6IFsyMDEzLTA0LTMwIERvIDE2 OjUwXS0tWzIwMTMtMDUtMDMgRG8gMTY6NTBdID0+IDcyOjAwCiAgIDpQUk9QRVJUSUVTOgog ICA6RWZmb3J0OiAgIDIwZAogICA6YWxsb2NhdGU6IGRldgogICA6dGFza19pZDogIHRhc2tf c3BlYwogICA6RU5EOgoqKiBTb2Z0d2FyZSBEZXZlbG9wbWVudAogICA6UFJPUEVSVElFUzoK ICAgOmFsbG9jYXRlOiBkZXYgICAKICAgOk9SREVSRUQ6ICB0cnVlCiAgIDpCTE9DS0VSOiAg cHJldmlvdXMtc2libGluZwogICA6dGFza19pZDogIHRhc2tfZGV2CiAgIDpFTkQ6CioqKiBU T0RPIERhdGFiYXNlIGNvdXBsaW5nCiAgICBDTE9DSzogWzIwMTMtMDUtMDMgRG8gMTU6MjFd LS1bMjAxMy0wNS0xMSBEbyAyMjoyMV0gPT4gMTk5OjAwCiAgICA6UFJPUEVSVElFUzoKICAg IDpFZmZvcnQ6ICAgMjBkCiAgICA6RU5EOgoKICAgICpUaGlzIHRhc2sgdXNlcyB0aGUgc21h cnQgcHJvZ3Jlc3MgaW5mZXJlbmNlKjogVGhpcyB0YXNrJ3MKICAgIGNvbXBsZXRlbmVzcyBp cyBndWVzc2VkIHVzaW5nIHRoZSBjbG9ja2VkIHRpbWVzLCBzaW5jZSBpdCBoYXMgbm8KICAg IGV4cGxpY2l0IGBjb21wbGV0ZScgcHJvcGVydHkuIEhvd2V2ZXIgdGhlIGNsb2NrIGR1cmF0 aW9ucyBhZGQgdXAKICAgIHRvIG1vcmUgdGhhbiB0aGUgZWZmb3J0IGFuZCBUSjMgZG9lcyBv bmx5IGFsbG93IHZhbHVlcwogICAgWzAsMTAwXS4gVGhlcmVmb3JlIHNlbWFudGljYWxseSB0 aGUgdGFzayBpcyBub3QgcmVnYXJkZWQgYXMKICAgIGNvbXBsZXRlIHVudGlsIHRoZSBUT0RP IHN0YXRlIGVxdWFscyAiZG9uZSIsIG5vIG1hdHRlciBob3cgbXVjaCB3ZQogICAgY2xvY2sg b24gaXQuICBBY2NvcmRpbmcgdG8gVEozIGRvYywgdGhlIGNvbXBsZXRlIGluZm9ybWF0aW9u IGhhcwogICAgbm8gaW1wYWN0IG9uIHRoZSBUSjMgc2NoZWR1bGVyLCBpdCdzIHB1cmUgZG9j dW1lbnRhdGlvbi4KCiAgICAqQWx0ZXJuYXRpdmVzKjogCiAgICAxKSBJbnN0ZWFkIG9mIHNl dHRpbmcgYGNvbXBsZXRlJywgd2UgY291bGQgc2V0IHRoZSBwcm9wZXJ0eQogICAgICAgYGJv b2tpbmcnIGZvciBhIHJlc291cmNlIG9yIHRhc2ssIHdoZW4gd2UgZXhwb3J0IHRvIFRKMy4g VGhlbgogICAgICAgVEozIHdvdWxkIGhhdmUgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiwgc2lu Y2UgdGhlIGJvb2tpbmdzCiAgICAgICByZWZsZWN0IGhvdyBtdWNoIHdvcmsgd2FzIGFjdHVh bGx5IHB1dCBpbnRvIGEgdGFzayB2cy4gaG93IG11Y2gKICAgICAgIHdlIG9yaWdpbmFsbHkg cGxhbm5lZC4gTm90ZSB0aGF0IHVubGlrZSBgY29tcGxldGUnIHRoaXMgaGFzIGFuCiAgICAg ICBpbXBhY3Qgb24gdGhlIHNjaGVkdWxpbmcuIFRKMyB0aGVuIGNhbiBzY2hlZHVsZSBhIG5l dyBwbGFuCiAgICAgICBiYXNlZCBvbiB0aGUgYW1vdW50IG9mIHdvcmsgdGhhdCBhY3R1YWxs eSBoYXBwZW5lZC4gIERvd25zaWRlCiAgICAgICBpcywgdGhhdCB0aGUgb3JnLXN5bnRheCBk b2VzIG5vdCBjYXB0dXJlIHdoby93aGljaCByZXNvdXJjZQogICAgICAgY2xvY2tzIG9uIGEg dGFzay4gQW5kIHRoYXQgdGhlIGNsb2NrIHRpbWVzIHdpbGwgY2F1c2UKICAgICAgIHNjaGVk dWxpbmcgZXJyb3JzIHdoZW4gdGhleSBkbyBub3QgY29tcGx5IHdpdGggdGhlIHNjaGVkdWxl ZAogICAgICAgdGltZSB3aW5kb3dzIGZvciB0aGUgdGFza3MgKGUuZy4sIHdoZW4gdGhlIGJv b2tpbmdzIGFyZSBlYXJsaWVyCiAgICAgICB0aGFuIHRoZSB0YXNrIGNvdWxkIGhhdmUgc3Rh cnRlZCwgd2hpY2ggY2FuIGJlIGNvbnN0cmFpbmVkIGJ5CiAgICAgICBkZXBlbmRlbmNpZXMp LiBXaGVuIHRoZSBib29raW5ncyBleGNlZWQgdGhlIGVmZm9ydCwgVEozIG92ZXJ3cml0ZXMg dGhlIGVmZm9ydCB3aXRoIHRoZSBib29raW5nIHZhbHVlLgogIAogICAgICAgTm8gY29tcGxl dGVuZXNzIGlzIGNhbGN1bGF0ZWQgYXV0b21hdGljYWxseSB0aG91Z2guCiAgICAyKSBXZSBj b250aW51ZSB0byBzZXQgYGNvbXBsZXRlJywgYnV0IHdoZW4gdGhlIHByb2dyZXNzIHJlbmRl cmVkCiAgICAgICBieSB0aGUgY2xvY2tzdW0gZXhjZWVkcyAxMDAlLCB3ZSBhZGp1c3QgdGhl IGVmZm9ydCBzLnQuIGl0CiAgICAgICB5aWVsZHMgOTklIGFnYWluLiBIb3dldmVyLCB0aGlz IG1pZ2h0IGJlIHN1cnByaXNpbmcgc2luY2UgdGhlCiAgICAgICBleHBvcnQgc2hvd3MgZGlm ZmVyZW50IGVmZm9ydHMgdGhhbiB0aGUgb3JnLWZpbGUuCgoKKioqIEJhY2stRW5kIEZ1bmN0 aW9ucwogICAgOlBST1BFUlRJRVM6CiAgICA6RWZmb3J0OiAgIDVkCiAgICA6dGFza19pZDog IHRhc2tfYmFja2VuZAogICAgOkVORDoKCioqKiBHcmFwaGljYWwgVXNlciBJbnRlcmZhY2UK ICAgIDpQUk9QRVJUSUVTOgogICAgOkVmZm9ydDogICAzNWQKICAgIDpFTkQ6CioqIFNvZnR3 YXJlIHRlc3RpbmcKICAgOlBST1BFUlRJRVM6CiAgIDphbGxvY2F0ZTogdGVzdCwgcGF1bAog ICA6T1JERVJFRDogIHRydWUKICAgOkJMT0NLRVI6ICB0YXNrX2RldgogICA6RU5EOgoqKiog QWxwaGEgVGVzdAogICAgOlBST1BFUlRJRVM6CiAgICA6RWZmb3J0OiAgIDVkCiAgICA6dGFz a19pZDogIHRhc2tfYWxwaGEKICAgIDpFTkQ6CioqKiBCZXRhIFRlc3QKICAgIDpQUk9QRVJU SUVTOgogICAgOkVmZm9ydDogICAyMGQKICAgIDphbGxvY2F0ZTogdGVzdAogICAgOnRhc2tf aWQ6ICB0YXNrX2JldGEKICAgIDpFTkQ6CioqIE1hbnVhbAogICAgQ0xPQ0s6IFsyMDEzLTA1 LTAzIEZyIDEyOjQ4XS0tWzIwMTMtMDUtMDggRnIgMTc6NDhdID0+IDEyNTowMAogICA6UFJP UEVSVElFUzoKICAgOkVmZm9ydDogICA1MGQKICAgOmFsbG9jYXRlOiBkb2MKICAgOkJMT0NL RVI6ICB0YXNrX3NwZWMKICAgOmNvbXBsZXRlOiA3NQogICA6dGFza19pZDogIHRhc2tfbWFu dWFsCiAgIDpFTkQ6CiAgICBUaGlzIHRhc2sncyBjb21wbGV0ZW5lc3MgaXMgZXhwbGljaXRs eSBzZXQuIEV2ZW4gaWYgdGhlcmUgYXJlCiAgICBjbG9jayBpbiB0aGlzIHRhc2ssIGl0IGlz IGJlaW5nIGlnbm9yZWQuCgoqKiBNaWxlc3RvbmVzCioqKiBQcm9qZWN0IHN0YXJ0CioqKiBU ZWNobm9sb2d5IFByZXZpZXcKICAgIDpQUk9QRVJUSUVTOgogICAgOkJMT0NLRVI6ICB0YXNr X2JhY2tlbmQKICAgIDpFTkQ6CioqKiBCZXRhIHZlcnNpb24KICAgIDpQUk9QRVJUSUVTOgog ICAgOkJMT0NLRVI6ICB0YXNrX2FscGhhCiAgICA6RU5EOgoqKiogU2hpcCBQcm9kdWN0IHRv IEN1c3RvbWVyCiAgICA6UFJPUEVSVElFUzoKICAgIDpCTE9DS0VSOiAgdGFza19iZXRhIHRh c2tfbWFudWFsCiAgICA6RU5EOgo= --------------070300000207080009000106--