Feature Request: Time Line in Lab Book

Feature Request: Time Line in Lab Book

[Dominik Schrempf]

Hello,

I want to write a lab book with Org mode.  Thereby my workflow is as
follows: New stuff is appended to the bottom of the document (with time
stamps in chronological order).  Sometimes, especially when I discuss
something in a meeting, tasks pop up that can only be done later.  These
tasks are filed into TODO entries.  However, new stuff is being appended
to the end of the document before I can come back to getting these tasks
done.  When I work on a task, I document it below this task and do not
append it to the bottom of the document.  This new stuff should belong
to that task and not to the top level (i.e., the time line).  New stuff
belonging to the time line should belong to the top level and not to any
task above it.  I want to fold tasks together with text belonging to
them while the time line is still visible below them.  I am not sure if
I make myself clear.

A possible example:

* February 2016
February 10th: Some text and stuff in February 2016.

** TODO A task to be done. Filed on February 10th.
   E.g., February 24th: Some text that should belong to the task only.
   I could not work on this task before February 18th.
   
February 18th: Some more text belonging to February 2016 and not to the
task.

* March 2016

And so on.  Maybe this feature does already exist, but I am not aware of
it.  I know that especially upon export, this is hard to realize,
because all text always belongs to the previous headline.  But maybe it
is worth thinking about it because at least to me this would be highly
useful (e.g., having different styles in HTML export for the text under
the task and the text of the top level, the time line).

Thanks and best wishes,
Dominik

Re: Feature Request: Time Line in Lab Book

[Eric S Fraga]

Hi Dominik,

it's not entirely clear what you want but I can suggest what I do.  I
use the following capture rule to add entries to my journal (equivalent
to your lab book):

#+begin_src emacs-lisp
  ("j" "journal" entry
   (file+datetree+prompt "~/s/notes/journal.org")
   "* %(format-time-string \"%H:%M\") %^{Entry} %^G\n%i%?")
#+end_src 

You could have two such capture rules, one for notes and one for TODO
items.  To add notes to the TODO items, you could use the logging
capability so that org prompts for a note every time a TODO item changes
state.  Have a look at org-log-state-notes-into-drawer.
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-668-g809a83

Re: Feature Request: Time Line in Lab Book

[Dominik Schrempf]

Hi Eric,

thanks for your answer.  I guess drawers in general are the solution to
my problems because then I can associate text to a specific headline.  I
introduced a DESCRIPTION drawer that includes the description of my
problem/task and I log the solution or outcome into the LOGBOOK drawer
when setting the state to DONE.  The drawer names are of course
arbitrary.  I also tried to use a single LOGBOOK drawer but Org mode
always adds notes at the top in the respective drawer.  I guess this is
fine in general but not expected behavior in this setting, that's why I
use two of them.

Thanks,
Dominik

On Thu, Mar 31 2016, Eric S Fraga wrote:
> Hi Dominik,
>
> it's not entirely clear what you want but I can suggest what I do.  I
> use the following capture rule to add entries to my journal (equivalent
> to your lab book):
>
> #+begin_src emacs-lisp
>   ("j" "journal" entry
>    (file+datetree+prompt "~/s/notes/journal.org")
>    "* %(format-time-string \"%H:%M\") %^{Entry} %^G\n%i%?")
> #+end_src 
>
> You could have two such capture rules, one for notes and one for TODO
> items.  To add notes to the TODO items, you could use the logging
> capability so that org prompts for a note every time a TODO item changes
> state.  Have a look at org-log-state-notes-into-drawer.

Re: Feature Request: Time Line in Lab Book

[Nick Dokos]

Dominik Schrempf <dominik.schrempf@gmail.com> writes:


> I want to write a lab book with Org mode.  Thereby my workflow is as
> follows: New stuff is appended to the bottom of the document (with time
> stamps in chronological order).  Sometimes, especially when I discuss
> something in a meeting, tasks pop up that can only be done later.  These
> tasks are filed into TODO entries.  However, new stuff is being appended
> to the end of the document before I can come back to getting these tasks
> done.  When I work on a task, I document it below this task and do not
> append it to the bottom of the document.  This new stuff should belong
> to that task and not to the top level (i.e., the time line).  New stuff
> belonging to the time line should belong to the top level and not to any
> task above it.  I want to fold tasks together with text belonging to
> them while the time line is still visible below them.  I am not sure if
> I make myself clear.
>

As Erik F. points out, a datetree capture is the way to go but...

> A possible example:
>
> * February 2016
> February 10th: Some text and stuff in February 2016.
>
> ** TODO A task to be done. Filed on February 10th.
>    E.g., February 24th: Some text that should belong to the task only.
>    I could not work on this task before February 18th.
>    
> February 18th: Some more text belonging to February 2016 and not to the
> task.
>
> * March 2016
>
> And so on.  Maybe this feature does already exist, but I am not aware of
> it.  I know that especially upon export, this is hard to realize,
> because all text always belongs to the previous headline.  But maybe it
> is worth thinking about it because at least to me this would be highly
> useful (e.g., having different styles in HTML export for the text under
> the task and the text of the top level, the time line).
>

Exactly. If tasks are implemented as second level headlines, then you
cannot do this: an org document is a tree and the second level subtree
is done only when the next headline (at whatever level) is
encountered. So the "Some more text..." will *not* belong to February
2016; it will belong to the task.

Maybe inline tasks can be used (but I have never used them, so I hope
somebody else chimes in).

-- 
Nick

Re: Feature Request: Time Line in Lab Book

[John Hendy]

On Thu, Mar 31, 2016 at 3:12 AM, Dominik Schrempf
<dominik.schrempf@gmail.com> wrote:
> Hello,
>

[snip]

> A possible example:
>
> * February 2016
> February 10th: Some text and stuff in February 2016.
>
> ** TODO A task to be done. Filed on February 10th.
>    E.g., February 24th: Some text that should belong to the task only.
>    I could not work on this task before February 18th.
>
> February 18th: Some more text belonging to February 2016 and not to the
> task.
>
> * March 2016

Like Eric, I'm a little confused of what you would want instead. The
above is great for what currently happens, but could you do a similar
example of what you want? You ask if this "feature" exists, but I'm
not sure what it would be... all I can envision as a modification to
above is:

* Feb 2016

Feb 10th: blah blah blah notes

Feb 18th: blah blah notes

** TODO filed feb 10th, but *done* on 2/24

> And so on.  Maybe this feature does already exist, but I am not aware of
> it.  I know that especially upon export, this is hard to realize,
> because all text always belongs to the previous headline.  But maybe it
> is worth thinking about it because at least to me this would be highly
> useful (e.g., having different styles in HTML export for the text under
> the task and the text of the top level, the time line).

I've wrestled with this a lot myself, at least if I put this in the
bucket of "what's the *best* way to organize an org file." To expand
on Nick's comments, something can only be in one hierarchy at a time,
and everything afterward will live in that parent/child, unless you
start a new sibling. The downside is you can't "escape" a current
sub-heading to return to "just the parent heading" again. I've not
quite wrestled with that, but moreso the desire to have one thing live
in several places at the same time. I posted some structure questions
when I migrated from TiddlyWiki in 2010; you could take a look at
these threads if you're interested:
- https://lists.gnu.org/archive/html/emacs-orgmode/2010-03/msg00390.html
- http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg01173.html

If your example is accurate, why not make everything it's own
headline? The notes from 2/18 wouldn't, then, "belong" to the todo
filed on 2/10 and completed on 2/24. You'd just have:

** Feb 10
blah blah
** TODO Feb 10 something
Notes about task
** Feb 18
blah blah

It seems the core of your issue is not being certain on whether or not
you want the TODO to be represented in the date tree according to
creation or completion. That, or you don't like that you have to
decouple the todo itself and your notes about it, which would lead to
separate entries, one for the todo on 2/10 and one for the notes about
what you did to complete it on 2/24. Are any of those accurate? I
think clarification would be helpful if I've missed what you're
wrestling with.

I've taken to a pure datetree for notes, with inline todos for
anything that comes up in the context of something else (and which I
want to keep in that context). So:

* Meeting about blah      :tag:
 [2016-03-31 Thu]

Notes here about thing

************* TODO some task

Notes I did about this todo
************* END

Otherwise, I have a separate tree just for tasks where I don't care if
they're decoupled from their context. It's just a headline called
"Tasks" which is my dumping ground for todos. My actual org file looks
like this:

* Tasks
** todo something 1
** todo something 2

* Journals
** 2016 March
*** Something
[2016-03-31 Thu]

Notes

*** Something else
[2016-03-30 Wed]

Blah

For the tasks, I often just delete them as I don't care, but for ones
where I've noted progress about them, I use C-c C-x A to archive them
in a subtree of "Tasks." Then I could search for the info in them down
the road if I want. I've also started just adding time stamps and
updates to other month's headlines if the activity is a continuation
of when it started. So maybe:

* Journals
** 2016 Feb
*** Experiment for projA
[2016-02-10 Wed]

Set up this experiment today...

[2016-03-02 Wed]
Ran a modified version of this experiment today... (and so on)

Hope that helps a little... I love thinking about org file strategies,
so please keep the thoughts coming if you'd like to discuss more!

John

>
> Thanks and best wishes,
> Dominik
>

Re: Feature Request: Time Line in Lab Book

[Dominik Schrempf]

Hi John,

thanks for your long answer.  I could take out a lot of it.  I think I
did not describe my problem well although all of you seemed to guess it!
Just a short rephrase with vocabulary from your posts:

I want a logbook/journal where I always append text about new stuff to
the end.  Only, when I work on a task that has arisen before, I file
this text under this task.  This text should belong to the task only.
Text after the task should belong to the top level (but this is not
possible as you pointed out).

The thing is, I can't really do this with headings only, because I often
append text after a task in the same minute and it does not make sense
to create a new headline then.  I now use drawers to achieve this.  That
was not intuitive to me but it seems to work well!  I can now fold the
task-specific text under the tasks.  If I expand all text but the
drawers, I get the view that I wanted (at least within Emacs).

The setup would be perfect if I could file tasks without headlines, kind
of (is this clear?).  This may correspond to what you called "inline
tasks" (because I want my tasks to show up next to where I take my
notes).

E.g.:
------------------------------
Top level entries.  This is all very interesting (A).

** TODO A task bla bla.
   :DESCRIPTION:
   We have to do this, because...
   And then, ten days later we finished it using...
   :END:

This is the top level again and text here may be written directly after
I wrote (A) from above and filed the task.
------------------------------

Do I make myself clear now?

Thanks,
Dominik

On Thu, Mar 31 2016, John Hendy wrote:
> On Thu, Mar 31, 2016 at 3:12 AM, Dominik Schrempf
> <dominik.schrempf@gmail.com> wrote:
>> Hello,
>>
>
> [snip]
>
>> A possible example:
>>
>> * February 2016
>> February 10th: Some text and stuff in February 2016.
>>
>> ** TODO A task to be done. Filed on February 10th.
>>    E.g., February 24th: Some text that should belong to the task only.
>>    I could not work on this task before February 18th.
>>
>> February 18th: Some more text belonging to February 2016 and not to the
>> task.
>>
>> * March 2016
>
> Like Eric, I'm a little confused of what you would want instead. The
> above is great for what currently happens, but could you do a similar
> example of what you want? You ask if this "feature" exists, but I'm
> not sure what it would be... all I can envision as a modification to
> above is:
>
> * Feb 2016
>
> Feb 10th: blah blah blah notes
>
> Feb 18th: blah blah notes
>
> ** TODO filed feb 10th, but *done* on 2/24
>
>> And so on.  Maybe this feature does already exist, but I am not aware of
>> it.  I know that especially upon export, this is hard to realize,
>> because all text always belongs to the previous headline.  But maybe it
>> is worth thinking about it because at least to me this would be highly
>> useful (e.g., having different styles in HTML export for the text under
>> the task and the text of the top level, the time line).
>
> I've wrestled with this a lot myself, at least if I put this in the
> bucket of "what's the *best* way to organize an org file." To expand
> on Nick's comments, something can only be in one hierarchy at a time,
> and everything afterward will live in that parent/child, unless you
> start a new sibling. The downside is you can't "escape" a current
> sub-heading to return to "just the parent heading" again. I've not
> quite wrestled with that, but moreso the desire to have one thing live
> in several places at the same time. I posted some structure questions
> when I migrated from TiddlyWiki in 2010; you could take a look at
> these threads if you're interested:
> - https://lists.gnu.org/archive/html/emacs-orgmode/2010-03/msg00390.html
> - http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg01173.html
>
> If your example is accurate, why not make everything it's own
> headline? The notes from 2/18 wouldn't, then, "belong" to the todo
> filed on 2/10 and completed on 2/24. You'd just have:
>
> ** Feb 10
> blah blah
> ** TODO Feb 10 something
> Notes about task
> ** Feb 18
> blah blah
>
> It seems the core of your issue is not being certain on whether or not
> you want the TODO to be represented in the date tree according to
> creation or completion. That, or you don't like that you have to
> decouple the todo itself and your notes about it, which would lead to
> separate entries, one for the todo on 2/10 and one for the notes about
> what you did to complete it on 2/24. Are any of those accurate? I
> think clarification would be helpful if I've missed what you're
> wrestling with.
>
> I've taken to a pure datetree for notes, with inline todos for
> anything that comes up in the context of something else (and which I
> want to keep in that context). So:
>
> * Meeting about blah      :tag:
>  [2016-03-31 Thu]
>
> Notes here about thing
>
> ************* TODO some task
>
> Notes I did about this todo
> ************* END
>
> Otherwise, I have a separate tree just for tasks where I don't care if
> they're decoupled from their context. It's just a headline called
> "Tasks" which is my dumping ground for todos. My actual org file looks
> like this:
>
> * Tasks
> ** todo something 1
> ** todo something 2
>
> * Journals
> ** 2016 March
> *** Something
> [2016-03-31 Thu]
>
> Notes
>
> *** Something else
> [2016-03-30 Wed]
>
> Blah
>
> For the tasks, I often just delete them as I don't care, but for ones
> where I've noted progress about them, I use C-c C-x A to archive them
> in a subtree of "Tasks." Then I could search for the info in them down
> the road if I want. I've also started just adding time stamps and
> updates to other month's headlines if the activity is a continuation
> of when it started. So maybe:
>
> * Journals
> ** 2016 Feb
> *** Experiment for projA
> [2016-02-10 Wed]
>
> Set up this experiment today...
>
> [2016-03-02 Wed]
> Ran a modified version of this experiment today... (and so on)
>
> Hope that helps a little... I love thinking about org file strategies,
> so please keep the thoughts coming if you'd like to discuss more!
>
> John
>
>>
>> Thanks and best wishes,
>> Dominik
>>

Re: Feature Request: Time Line in Lab Book

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 618 bytes --]

On Tuesday,  5 Apr 2016 at 15:12, Dominik Schrempf wrote:
> Do I make myself clear now?

Yes and I think the key would be to ensure that every note etc. has a
heading.  This avoids all the problems you have with non-terminated
entries.  Avoid a flat structure and org works very well.

For instance, if you use a capture rule based on a date-tree, you can
easily add to the end of the file while still add notes later to any
previous entry.  Plus you have the advantage of knowing when notes were
added.  See screenshot where I have added three notes and then went and
added some text to the first note I took today.


[-- Attachment #2: screendump-20160405142955.png --]
[-- Type: image/png, Size: 48293 bytes --]

[-- Attachment #3: Type: text/plain, Size: 149 bytes --]


The notes were added using my journal capture rule posted earlier.

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.92.1, Org release_8.3.4-668-g809a83

Re: Feature Request: Time Line in Lab Book

[Charles Millar]

[-- Attachment #1: Type: text/plain, Size: 964 bytes --]



On 04/05/2016 09:34 AM, Eric S Fraga wrote:
> On Tuesday,  5 Apr 2016 at 15:12, Dominik Schrempf wrote:
>> Do I make myself clear now?
> Yes and I think the key would be to ensure that every note etc. has a
> heading.  This avoids all the problems you have with non-terminated
> entries.  Avoid a flat structure and org works very well.
>
> For instance, if you use a capture rule based on a date-tree, you can
> easily add to the end of the file while still add notes later to any
> previous entry.  Plus you have the advantage of knowing when notes were
> added.  See screenshot where I have added three notes and then went and
> added some text to the first note I took today.
>
>
>
> The notes were added using my journal capture rule posted earlier.
>
A few years ago I found code for a journal entry at Metjack that is not 
org-capture (or org-remember as it was at that time)

https://metajack.im/2009/01/01/journaling-with-emacs-orgmode/

Charlie Millar

[-- Attachment #2: Type: text/html, Size: 1645 bytes --]

Re: Feature Request: Time Line in Lab Book

[John Hendy]

On Tue, Apr 5, 2016 at 8:12 AM, Dominik Schrempf
<dominik.schrempf@gmail.com> wrote:
> Hi John,
>
> thanks for your long answer.  I could take out a lot of it.  I think I
> did not describe my problem well although all of you seemed to guess it!
> Just a short rephrase with vocabulary from your posts:
>
> I want a logbook/journal where I always append text about new stuff to
> the end.  Only, when I work on a task that has arisen before, I file
> this text under this task.  This text should belong to the task only.
> Text after the task should belong to the top level (but this is not
> possible as you pointed out).
>
> The thing is, I can't really do this with headings only, because I often
> append text after a task in the same minute and it does not make sense
> to create a new headline then.  I now use drawers to achieve this.  That
> was not intuitive to me but it seems to work well!  I can now fold the
> task-specific text under the tasks.  If I expand all text but the
> drawers, I get the view that I wanted (at least within Emacs).
>
> The setup would be perfect if I could file tasks without headlines, kind
> of (is this clear?).  This may correspond to what you called "inline
> tasks" (because I want my tasks to show up next to where I take my
> notes).
>
> E.g.:
> ------------------------------
> Top level entries.  This is all very interesting (A).
>
> ** TODO A task bla bla.
>    :DESCRIPTION:
>    We have to do this, because...
>    And then, ten days later we finished it using...
>    :END:
>
> This is the top level again and text here may be written directly after
> I wrote (A) from above and filed the task.
> ------------------------------
>
> Do I make myself clear now?

I think so, and thus I can really only think of a couple options if
you need to have the structure you describe (aside from your leaning
toward drawers):

- inline tasks: they're just sort of "meta data" within whatever
you're currently typing, so that makes sense. If I understand
correctly, you're treating the task as just a "this is an action
amidst these notes," but the notes might continue on after that task
is documented.

- regular headlines: I *still* think this could work and may be wrong,
but think you mentally dislike the org hierarchy more than anything
being "wrong," per se, about how it's organized. Said another way, you
want the task to appear chronologically where it arose, even though it
doesn't *need* to appear there... With a simply modification of making
a headline per day, all would seem to be resolved, no?

#+begin_example
* 2016 April
** 2016 April 05

*** Thing 1

This is all very interesting. I only belongs to logs for 2016 April.

*** TODO a task

This is in the contents of a task that came up on April 5th. It only
belongs to the day's log.

*** Thing 2

This is also very interesting, and includes a task belonging to these notes.

Here are more notes

**** TODO a task

Here is a task which belongs to Thing 2, April 5th, and April 2016. I
inserted it at the very end of Thing 2 so that none of the non-todo
based stuff about Thing 2 belongs to this task
#+end_example

Is it the levels of hierarchy that bother you about this approach? I
may have misread your initial request, but I wrestled with this
initially with org, finally accepting that it's all about headlines.
They're far more compatible with agenda, more meta data (e.g. drawers,
tags, etc.) can be attached, and re-arranging is easier.

Moving to drawers is up to you. I personally dislike accessing/editing
them. Search this manual page for "drawer" and then search it for
"headline" and "subtree"...
- http://orgmode.org/manual/Structure-editing.html

I use C-c C-[n/p/U] a lot, which gets you to the next headline. It
just seems like extra work to arrow down and TAB on the drawer when
the same can be accomplished in a headline. Looking at your example,
I've started to do something similar with some of my headlines when I
get new information or revisit things. I work in R&D, and am often
doing follow-up experiments or continuations of some previous work. I
used to go through the effort of linking between related headlines,
i.e. creating a main headline do document the work when I started,
then a headline in perhaps another month's tree with the continuation.
I'd =C-c l= on the old headline and then =C-c C-l= to insert a link
like:

#+begin_example

* Some description
[2016-04-04 Mon]

Today I re-did [[id:2745364e-8692-43ff-9d3c-89bdbf265d5e][this
experiment]] with such and such modifications.
#+end_example

Now for the sake of ease I often just refind the original and do:

#+begin_example

* Some description
[2016-03-21 Mon]

Did an experiment today about blah...

[2016-04-04 Mon]

This is the experiment I did today after the observations from above:
tables, data, code, whatever...

#+end_example

The mental block, at least I've found, was in my own mind... Keep in
mind the above are just examples; they'd be within some top level
headline (which I've called "Journals") and a sub heading for the
month (e.g. "2016 March"). Should the experiment(s) belong to the 2016
March headline or 2016 April? Are they really the same work done at
different times or genuinely separate efforts? Before that I was
pretty obsessed with data being associated with a specific project,
and I maintained time-stamped journals within many separate top-level
project headlines. This is probably made clear in the mailing list
links I provided; I wanted the notes in Org to match my mental model,
which was that the work was done for a *project* but also at a
specific *time*.

Finally I just gave up and adopted the time-based model. For me, it
came down to asking myself how I would actually *use* Org mode. Maybe
10-25% of the times I pop open Emacs I'm adding content. The rest is
almost entirely to access data stored in Org through C-s or C-a s
followed by visiting the headline. Since I'm often after several bits
of data about the same general thing, I'm find with leaving the
initial work and all follow-ups under the same date tree (generally
when it was initiated). This way, I can just scroll through the
paragraphs and "re-live" the order of events.

In large part, this was when the US moved away from a first to invent
intellectual property system. I used to have to document my daily
work, so chronological order was really important and thus
printing/witnessing efforts made more sense chronologically as to not
forget new work hiding under a past headline that I'd already printed.
Not the US is first to file so I no longer have to maintain that sort
of documentation.

Alright, going to wrap up that novel! Good luck in finding a solution
that works for you. This might seem like a nightmare to you, but you
could always try a few different ways, each for a week or month and
then compare how they work in terms of content generation as well as
how you end up accessing/using said content? Just an idea!


Best regards,
John

> Thanks,
> Dominik
>
> On Thu, Mar 31 2016, John Hendy wrote:
>> On Thu, Mar 31, 2016 at 3:12 AM, Dominik Schrempf
>> <dominik.schrempf@gmail.com> wrote:
>>> Hello,
>>>
>>
>> [snip]
>>
>>> A possible example:
>>>
>>> * February 2016
>>> February 10th: Some text and stuff in February 2016.
>>>
>>> ** TODO A task to be done. Filed on February 10th.
>>>    E.g., February 24th: Some text that should belong to the task only.
>>>    I could not work on this task before February 18th.
>>>
>>> February 18th: Some more text belonging to February 2016 and not to the
>>> task.
>>>
>>> * March 2016
>>
>> Like Eric, I'm a little confused of what you would want instead. The
>> above is great for what currently happens, but could you do a similar
>> example of what you want? You ask if this "feature" exists, but I'm
>> not sure what it would be... all I can envision as a modification to
>> above is:
>>
>> * Feb 2016
>>
>> Feb 10th: blah blah blah notes
>>
>> Feb 18th: blah blah notes
>>
>> ** TODO filed feb 10th, but *done* on 2/24
>>
>>> And so on.  Maybe this feature does already exist, but I am not aware of
>>> it.  I know that especially upon export, this is hard to realize,
>>> because all text always belongs to the previous headline.  But maybe it
>>> is worth thinking about it because at least to me this would be highly
>>> useful (e.g., having different styles in HTML export for the text under
>>> the task and the text of the top level, the time line).
>>
>> I've wrestled with this a lot myself, at least if I put this in the
>> bucket of "what's the *best* way to organize an org file." To expand
>> on Nick's comments, something can only be in one hierarchy at a time,
>> and everything afterward will live in that parent/child, unless you
>> start a new sibling. The downside is you can't "escape" a current
>> sub-heading to return to "just the parent heading" again. I've not
>> quite wrestled with that, but moreso the desire to have one thing live
>> in several places at the same time. I posted some structure questions
>> when I migrated from TiddlyWiki in 2010; you could take a look at
>> these threads if you're interested:
>> - https://lists.gnu.org/archive/html/emacs-orgmode/2010-03/msg00390.html
>> - http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg01173.html
>>
>> If your example is accurate, why not make everything it's own
>> headline? The notes from 2/18 wouldn't, then, "belong" to the todo
>> filed on 2/10 and completed on 2/24. You'd just have:
>>
>> ** Feb 10
>> blah blah
>> ** TODO Feb 10 something
>> Notes about task
>> ** Feb 18
>> blah blah
>>
>> It seems the core of your issue is not being certain on whether or not
>> you want the TODO to be represented in the date tree according to
>> creation or completion. That, or you don't like that you have to
>> decouple the todo itself and your notes about it, which would lead to
>> separate entries, one for the todo on 2/10 and one for the notes about
>> what you did to complete it on 2/24. Are any of those accurate? I
>> think clarification would be helpful if I've missed what you're
>> wrestling with.
>>
>> I've taken to a pure datetree for notes, with inline todos for
>> anything that comes up in the context of something else (and which I
>> want to keep in that context). So:
>>
>> * Meeting about blah      :tag:
>>  [2016-03-31 Thu]
>>
>> Notes here about thing
>>
>> ************* TODO some task
>>
>> Notes I did about this todo
>> ************* END
>>
>> Otherwise, I have a separate tree just for tasks where I don't care if
>> they're decoupled from their context. It's just a headline called
>> "Tasks" which is my dumping ground for todos. My actual org file looks
>> like this:
>>
>> * Tasks
>> ** todo something 1
>> ** todo something 2
>>
>> * Journals
>> ** 2016 March
>> *** Something
>> [2016-03-31 Thu]
>>
>> Notes
>>
>> *** Something else
>> [2016-03-30 Wed]
>>
>> Blah
>>
>> For the tasks, I often just delete them as I don't care, but for ones
>> where I've noted progress about them, I use C-c C-x A to archive them
>> in a subtree of "Tasks." Then I could search for the info in them down
>> the road if I want. I've also started just adding time stamps and
>> updates to other month's headlines if the activity is a continuation
>> of when it started. So maybe:
>>
>> * Journals
>> ** 2016 Feb
>> *** Experiment for projA
>> [2016-02-10 Wed]
>>
>> Set up this experiment today...
>>
>> [2016-03-02 Wed]
>> Ran a modified version of this experiment today... (and so on)
>>
>> Hope that helps a little... I love thinking about org file strategies,
>> so please keep the thoughts coming if you'd like to discuss more!
>>
>> John
>>
>>>
>>> Thanks and best wishes,
>>> Dominik
>>>