emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Malcolm Matalka <mmatalka@gmail.com>
To: Marcin Borkowski <mbork@mbork.pl>
Cc: emacs-orgmode@gnu.org
Subject: Re: Tracking time from one state to another?
Date: Mon, 22 Apr 2019 16:09:31 +0200	[thread overview]
Message-ID: <86v9z6cesk.fsf@gmail.com> (raw)
In-Reply-To: <87lg06hap5.fsf@mbork.pl>


Marcin Borkowski <mbork@mbork.pl> writes:

> On 2019-04-18, at 17:34, Malcolm Matalka <mmatalka@gmail.com> wrote:
>
>> Marcin Borkowski <mbork@mbork.pl> writes:
>>
>>> On 2019-04-17, at 14:20, Malcolm Matalka <mmatalka@gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> Is it possible in org-mode to track, and report, the duration of certain
>>>> state transitions in org-mode?  In particular, I'm interested in
>>>> tracking how long it takes me to go from a state that means I'm actively
>>>> working on an item to it being in a done state?
>>>>
>>>> In my case, an item might go from working, to waiting, to working, to
>>>> done.  And in this case I'm only really interested in the last working
>>>> to done time.
>>>>
>>>> For my case, I'm looking to do a weekly report on how long it takes me
>>>> to complete tasks that I have said I will work on.
>>>
>>> Hi Malcolm,
>>>
>>> that sounds interesting.  Since you can turn on logging of state changes
>>> (as you probably know), this is in principle possible, though I don't
>>> think it is built in.
>>>
>>> I guess writing a bit of Elisp to accomplish this should not be very
>>> difficult, though it seems that currently the problem is a bit
>>> underspecified.  If you could elaborate, e.g., provide an example of
>>> your state change log and describe the result you would like to get,
>>> I could be tempted to coding this.
>>>
>>> Best,
>>
>> Sure!
>>
>> So for my use case, I'm mostly interested in the last transition to a
>> finished state, but for simplicity I'll specify the two states I'm
>> interested in:
>>
>> Given states NEXT and DONE, I want to know the time between going into
>> NEXT and over to DONE.
>>
>> For example, given the following logbook:
>>
>>    :LOGBOOK:
>>    - State "DONE"       from "NEXT"       [2019-04-01 Mon 11:07]
>>    - State "NEXT"       from "TODO"       [2019-04-01 Mon 10:35]
>>    - State "NEXT"       from "TODO"       [2018-07-02 Mon 11:03]
>>    :END:
>>
>>
>> This item would be 32 minutes.
>>
>> This one:
>>
>>    :LOGBOOK:
>>    - State "DONE"       from "NEXT"       [2019-04-10 Wed 09:56]
>>    - State "NEXT"       from "WAITING"    [2019-04-10 Wed 09:40]
>>    - State "WAITING"    from "NEXT"       [2019-04-09 Tue 10:44]
>>    - State "NEXT"       from "WAITING"    [2019-04-09 Tue 10:10]
>>    - State "WAITING"    from "NEXT"       [2019-04-08 Mon 16:39]
>>    - State "NEXT"       from "TODO"       [2019-04-08 Mon 11:14]
>>    :END:
>>
>>
>> Would be 16 minutes.
>
> Are those :LOGBOOK: drawers real?  They are not sorted chronologically,
> as they probably should be (though I'm not sure, I don't se them
> much).

Yes they are real.  I'm not tracking going into a TODO state which is
hwy the first one looks funny.  And they are sorted chronologically, but
in reverse order, so top is most recent.

>
>> I'd like to specify what time range to do this for, and be able to sort
>> by duration.
>>
>> I think a dynamic block, like clocktable, would probably be a fine.
>>
>> Any idea what the level of work involved is to accomplish this?  I'm
>> guessing a very hacky version might be to modify clock table and look at
>> the logbook instead of clock and filter out all but the last transition?
>
> I don't think that's the best way - Org-mode code is famously
> complicated, it might be easier to do it from scratch (it'd be perhaps
> less general then, though).
>
> Anyway, it doesn't look like a lot of work - an hour or two for a rough
> prototype might be enough.

Is this something you're interested in doing?  If not if you have a
pointers I can try to take a poke at it.  My elisp skills are very-much
lacking but some progress is better than no progress.

>
>> Also, this is just the usecase I'm interested in, so if you have
>> thoughts on what a more general form would look like, that would be interested.
>
> No idea yet.
>
> Best,

  parent reply	other threads:[~2019-04-22 14:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-17 12:20 Tracking time from one state to another? Malcolm Matalka
2019-04-18 11:25 ` Marcin Borkowski
2019-04-18 15:34   ` Malcolm Matalka
2019-04-19  4:37     ` Marcin Borkowski
2019-04-20 18:55       ` Julius Dittmar
2019-04-22 14:09       ` Malcolm Matalka [this message]
2019-04-22 14:27 ` Ken Mankoff
2019-04-23  6:07   ` Malcolm Matalka
2019-04-23  6:32     ` Ken Mankoff
2019-04-23  9:00       ` Malcolm Matalka

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=86v9z6cesk.fsf@gmail.com \
    --to=mmatalka@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=mbork@mbork.pl \
    /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).