org-log-done vs. State Logbook

org-log-done vs. State Logbook

[Yuri Niyazov]

Hi everyone,


  So, I am trying to learn org-mode and figure out what's best for me.
One of the things that I would like to see is how long a TODO task
takes to travel through my life, on average from the moment when it is
captured, to scheduled, to done. Does something like this already
exists?

One of the things I learned earlier today from this thread
https://lists.gnu.org/archive/html/emacs-orgmode/2011-10/msg00112.html
was that there's nothing that allows you to log state at the moment of
capture, so I created a capture template with a LOGBOOK drawer
included with an initial state change, like this:

"* TODO %?
SCHEDULED: %^t
:LOGBOOK:
- State \"CAPTURED\"   from \"\"           %u
:END:"

Now, one of the things that I am finding hard to figure out is what to
do at the end: there's both the ability to log when the object is done
using org-log-done, and one can also track every state change, which
includes the final state change of being done, with LOGBOOK state
changes. I am leaning towards turning them both on going forward, but
I have a bunch of old tasks, and some of them only have the CLOSED:
[timestamp] entry, and some of them only have the -State "DONE" from
"TODO" line in Logbook, and I don't know whether to invest the time
into fixing up the old entries to mirror the existing ones. The answer
to this depends on whether a package for for displaying statistics to
me already exists, and if it depends on one of those (CLOSED entry vs.
Logbook state changes).

I know about clocktable, but clocktable seems to only be for
Clocking-in and Clocking-out entries, not across the lifetime of a
task.

Re: org-log-done vs. State Logbook

[Eric Abrahamsen]

Yuri Niyazov <yuri.niyazov@gmail.com> writes:

> Hi everyone,
>
>
>   So, I am trying to learn org-mode and figure out what's best for me.
> One of the things that I would like to see is how long a TODO task
> takes to travel through my life, on average from the moment when it is
> captured, to scheduled, to done. Does something like this already
> exists?
>
> One of the things I learned earlier today from this thread
> https://lists.gnu.org/archive/html/emacs-orgmode/2011-10/msg00112.html
> was that there's nothing that allows you to log state at the moment of
> capture, so I created a capture template with a LOGBOOK drawer
> included with an initial state change, like this:
>
> "* TODO %?
> SCHEDULED: %^t
> :LOGBOOK:
> - State \"CAPTURED\"   from \"\"           %u
> :END:"
>
> Now, one of the things that I am finding hard to figure out is what to
> do at the end: there's both the ability to log when the object is done
> using org-log-done, and one can also track every state change, which
> includes the final state change of being done, with LOGBOOK state
> changes. I am leaning towards turning them both on going forward, but
> I have a bunch of old tasks, and some of them only have the CLOSED:
> [timestamp] entry, and some of them only have the -State "DONE" from
> "TODO" line in Logbook, and I don't know whether to invest the time
> into fixing up the old entries to mirror the existing ones. The answer
> to this depends on whether a package for for displaying statistics to
> me already exists, and if it depends on one of those (CLOSED entry vs.
> Logbook state changes).
>
> I know about clocktable, but clocktable seems to only be for
> Clocking-in and Clocking-out entries, not across the lifetime of a
> task.

You could maybe take a look at org-habit? I haven't really used it, so I
can't tell you about its ins and outs, but it might be useful. On the
other hand, it seems to be mostly for repeating habits. Dunno what else
there is...

Re: org-log-done vs. State Logbook

[Yuri Niyazov]

Thank you. I am already using it, and org-habit really is for habits,
rather than for individual tasks. The closest non-Org analogy I can
think of what I am trying to implement is (for the programmers out
there) the "SCRUM" development methodology. I know it has its
detractors and is quite controversial, but the one aspect of it that I
liked when I was exposed to it is that it required someone to keep
track of how long it took a task, on average, to go from "created" to
"completed" stage.

On Sat, Jan 3, 2015 at 8:45 PM, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
> Yuri Niyazov <yuri.niyazov@gmail.com> writes:
>
>> Hi everyone,
>>
>>
>>   So, I am trying to learn org-mode and figure out what's best for me.
>> One of the things that I would like to see is how long a TODO task
>> takes to travel through my life, on average from the moment when it is
>> captured, to scheduled, to done. Does something like this already
>> exists?
>>
>> One of the things I learned earlier today from this thread
>> https://lists.gnu.org/archive/html/emacs-orgmode/2011-10/msg00112.html
>> was that there's nothing that allows you to log state at the moment of
>> capture, so I created a capture template with a LOGBOOK drawer
>> included with an initial state change, like this:
>>
>> "* TODO %?
>> SCHEDULED: %^t
>> :LOGBOOK:
>> - State \"CAPTURED\"   from \"\"           %u
>> :END:"
>>
>> Now, one of the things that I am finding hard to figure out is what to
>> do at the end: there's both the ability to log when the object is done
>> using org-log-done, and one can also track every state change, which
>> includes the final state change of being done, with LOGBOOK state
>> changes. I am leaning towards turning them both on going forward, but
>> I have a bunch of old tasks, and some of them only have the CLOSED:
>> [timestamp] entry, and some of them only have the -State "DONE" from
>> "TODO" line in Logbook, and I don't know whether to invest the time
>> into fixing up the old entries to mirror the existing ones. The answer
>> to this depends on whether a package for for displaying statistics to
>> me already exists, and if it depends on one of those (CLOSED entry vs.
>> Logbook state changes).
>>
>> I know about clocktable, but clocktable seems to only be for
>> Clocking-in and Clocking-out entries, not across the lifetime of a
>> task.
>
> You could maybe take a look at org-habit? I haven't really used it, so I
> can't tell you about its ins and outs, but it might be useful. On the
> other hand, it seems to be mostly for repeating habits. Dunno what else
> there is...
>
>

Re: org-log-done vs. State Logbook

[Yuri Niyazov]

as soon as I typed that out I googled org mode scrum and found
https://github.com/ianxm/emacs-scrum so I'll be giving that a look.
Thanks for stimulating my brain :)

On Sat, Jan 3, 2015 at 8:57 PM, Yuri Niyazov <yuri.niyazov@gmail.com> wrote:
> Thank you. I am already using it, and org-habit really is for habits,
> rather than for individual tasks. The closest non-Org analogy I can
> think of what I am trying to implement is (for the programmers out
> there) the "SCRUM" development methodology. I know it has its
> detractors and is quite controversial, but the one aspect of it that I
> liked when I was exposed to it is that it required someone to keep
> track of how long it took a task, on average, to go from "created" to
> "completed" stage.
>
> On Sat, Jan 3, 2015 at 8:45 PM, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>> Yuri Niyazov <yuri.niyazov@gmail.com> writes:
>>
>>> Hi everyone,
>>>
>>>
>>>   So, I am trying to learn org-mode and figure out what's best for me.
>>> One of the things that I would like to see is how long a TODO task
>>> takes to travel through my life, on average from the moment when it is
>>> captured, to scheduled, to done. Does something like this already
>>> exists?
>>>
>>> One of the things I learned earlier today from this thread
>>> https://lists.gnu.org/archive/html/emacs-orgmode/2011-10/msg00112.html
>>> was that there's nothing that allows you to log state at the moment of
>>> capture, so I created a capture template with a LOGBOOK drawer
>>> included with an initial state change, like this:
>>>
>>> "* TODO %?
>>> SCHEDULED: %^t
>>> :LOGBOOK:
>>> - State \"CAPTURED\"   from \"\"           %u
>>> :END:"
>>>
>>> Now, one of the things that I am finding hard to figure out is what to
>>> do at the end: there's both the ability to log when the object is done
>>> using org-log-done, and one can also track every state change, which
>>> includes the final state change of being done, with LOGBOOK state
>>> changes. I am leaning towards turning them both on going forward, but
>>> I have a bunch of old tasks, and some of them only have the CLOSED:
>>> [timestamp] entry, and some of them only have the -State "DONE" from
>>> "TODO" line in Logbook, and I don't know whether to invest the time
>>> into fixing up the old entries to mirror the existing ones. The answer
>>> to this depends on whether a package for for displaying statistics to
>>> me already exists, and if it depends on one of those (CLOSED entry vs.
>>> Logbook state changes).
>>>
>>> I know about clocktable, but clocktable seems to only be for
>>> Clocking-in and Clocking-out entries, not across the lifetime of a
>>> task.
>>
>> You could maybe take a look at org-habit? I haven't really used it, so I
>> can't tell you about its ins and outs, but it might be useful. On the
>> other hand, it seems to be mostly for repeating habits. Dunno what else
>> there is...
>>
>>

Re: org-log-done vs. State Logbook

[Eric Abrahamsen]

Yuri Niyazov <yuri.niyazov@gmail.com> writes:

> as soon as I typed that out I googled org mode scrum and found
> https://github.com/ianxm/emacs-scrum so I'll be giving that a look.
> Thanks for stimulating my brain :)

Thanks for giving me something to google!

> On Sat, Jan 3, 2015 at 8:57 PM, Yuri Niyazov <yuri.niyazov@gmail.com> wrote:
>> Thank you. I am already using it, and org-habit really is for habits,
>> rather than for individual tasks. The closest non-Org analogy I can
>> think of what I am trying to implement is (for the programmers out
>> there) the "SCRUM" development methodology. I know it has its
>> detractors and is quite controversial, but the one aspect of it that I
>> liked when I was exposed to it is that it required someone to keep
>> track of how long it took a task, on average, to go from "created" to
>> "completed" stage.
>>
>> On Sat, Jan 3, 2015 at 8:45 PM, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>>> Yuri Niyazov <yuri.niyazov@gmail.com> writes:
>>>
>>>> Hi everyone,
>>>>
>>>>
>>>>   So, I am trying to learn org-mode and figure out what's best for me.
>>>> One of the things that I would like to see is how long a TODO task
>>>> takes to travel through my life, on average from the moment when it is
>>>> captured, to scheduled, to done. Does something like this already
>>>> exists?
>>>>
>>>> One of the things I learned earlier today from this thread
>>>> https://lists.gnu.org/archive/html/emacs-orgmode/2011-10/msg00112.html
>>>> was that there's nothing that allows you to log state at the moment of
>>>> capture, so I created a capture template with a LOGBOOK drawer
>>>> included with an initial state change, like this:
>>>>
>>>> "* TODO %?
>>>> SCHEDULED: %^t
>>>> :LOGBOOK:
>>>> - State \"CAPTURED\"   from \"\"           %u
>>>> :END:"
>>>>
>>>> Now, one of the things that I am finding hard to figure out is what to
>>>> do at the end: there's both the ability to log when the object is done
>>>> using org-log-done, and one can also track every state change, which
>>>> includes the final state change of being done, with LOGBOOK state
>>>> changes. I am leaning towards turning them both on going forward, but
>>>> I have a bunch of old tasks, and some of them only have the CLOSED:
>>>> [timestamp] entry, and some of them only have the -State "DONE" from
>>>> "TODO" line in Logbook, and I don't know whether to invest the time
>>>> into fixing up the old entries to mirror the existing ones. The answer
>>>> to this depends on whether a package for for displaying statistics to
>>>> me already exists, and if it depends on one of those (CLOSED entry vs.
>>>> Logbook state changes).
>>>>
>>>> I know about clocktable, but clocktable seems to only be for
>>>> Clocking-in and Clocking-out entries, not across the lifetime of a
>>>> task.
>>>
>>> You could maybe take a look at org-habit? I haven't really used it, so I
>>> can't tell you about its ins and outs, but it might be useful. On the
>>> other hand, it seems to be mostly for repeating habits. Dunno what else
>>> there is...
>>>
>>>