From: Ihor Radchenko <yantar92@gmail.com>
To: Allen Li <darkfeline@felesatra.moe>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [feature request] A new cookie type [!] showing the last note taken
Date: Sun, 06 Sep 2020 09:23:24 +0800 [thread overview]
Message-ID: <87pn6zzoj7.fsf@localhost> (raw)
In-Reply-To: <CADbSrJxmToOvqoCgq=10nwm3hvqOS3Gixio52TuqdBb9bXp9Sg@mail.gmail.com>
> Everyone has their own workflows, but I think the way you are approaching
> this problem is "wrong".
I think I need to elaborate on the use-cases more then.
I am well aware about the concept of NEXT actions, GTD, projects, and
using categories to bring task context in agenda. However, the problem I
am trying to solve is more subtle.
Sometimes, subdividing a task into NEXT sub-tasks is simply overkill
leading to redundancy. Consider the following example of reading a book,
when the task of reading is also part of bigger project:
* PROJECT Combine GTD approach with Zettelkasten in org-mode
:PROPERTIES:
:CATEGORY: ZettelOrg
:END:
Zettelkasten method looks promising to combine many pieces of
information from various research papers together. However, most of
papers I read are initially captured as TODO - within framework of GTD.
The original GTD approach recommends separating reference materials and
the todo-lists. I need to explore the reasons why it is so in more
details and decide if I need to separate paper notes from their "read"
tasks and how to manage the separation if I decide to do it.
** Literature review
*** NEXT re-read Getting Things Done by David Allen
[[attachment:GTD.pdf]]
----------------------------
That's indeed a fairly big task - reading the whole book. Splitting the
task sounds reasonable:
*** NEXT re-read Getting Things Done by David Allen
[[attachment:GTD.pdf]]
**** NEXT Read Chapter 1
**** TODO Read Chapter 2
**** TODO Read Chapter 3
<...>
----------------------------
There is a problem with this approach though - individual tasks will
appear without context in agenda:
* today NEXT Read Chapter 1
As you mentioned, we can bring some context to the task simply by
showing category:
* today ZettelOrg: NEXT Read Chapter 1
You can see the problem - we already have high-level category for the
project.
Of course, we can define separate category just for the "re-read" task.
But then, we will lose the information about higher-level project. If
you look at the project description I put in the example, you can see
that the higher-level context is, in fact, important - I do not intend to
read the GTD book in generic way, but I intend to explore the possible
combination of Zettelkasten and GTD. This context is general for the
whole project and will apply to other books/articles that may appear in
the project "to-read" list.
There is also another approach to bring context to the individual "Read
Chapter" tasks - we can mention the book title in all of them:
*** NEXT re-read Getting Things Done by David Allen
[[attachment:GTD.pdf]]
**** NEXT Read Chapter 1. Getting Things Done by David Allen
**** TODO Read Chapter 2. Getting Things Done by David Allen
**** TODO Read Chapter 3. Getting Things Done by David Allen
<...>
This works fine, but it is redundant - we have to carry over the first
headline to every sub-task.
So, I suggest to add a short note to the main task instead:
*** NEXT chapter 1 | re-read Getting Things Done by David Allen
[[attachment:GTD.pdf]]
This is much shorter and does not require creating a bunch of similar
tasks. I just need to look at the main task in the morning and decide
what I am going to do with it that day (like read first chapter).
One can argue that the fact that I want to read a chapter of the book is
so trivial that there is no need to bother writing it down. However, it
actually helps tremendously. Look at the following two tasks:
* today NEXT re-read Getting Things Done by David Allen
* today NEXT chapter 1 | re-read Getting Things Done by David Allen
According to my experience using GTD + agenda, I tend to feel a little
depressed by looking at the first task - "OMG, I need to read the whole
book! Better go ahead and clock-in an easier task - I can finish it
quickly." Thinking that I can just read a single chapter is not
something coming to my mind immediately - I need extra effort to realise
it. And things become worse when we have a task, which is less trivial
than reading a book (but also requires simple repetitive [but less
obvious] actions).
Finally, note that I have an attachment link to the book in the task
description:
*** NEXT re-read Getting Things Done by David Allen
[[attachment:GTD.pdf]]
This is handy, because I can open this link directly from agenda view
via C-c C-o. If I had to create individual tasks for each chapter, I
would need to carry over the link as well - another bit of redundancy.
> Under the GTD methodology, there is the concept
> of a project (some higher goal to be achieved) and next actions (the
> concrete tasks to do next to achieve the project). You would only track
> the next action in your regular toto list. In Org mode, this would look
> like:
>
> * PROJECT make babel support org file links in header args (:file or :dir)
> ** TODO Finish the text prop org-mode
>
> My anecdotal impression is that many people using Org do this (see
> https://orgmode.org/worg/org-gtd-etc.html), so they have no need for a
> "last note taken embedded in headline" feature. As a practical matter, I
> would find it inconvenient to have both the "last note take"/"next action"
> and the overall project headline appear in the agenta view because it makes
> the text too wide. If I need to associate the next action with the overall
> project, I take advantage of the CATEGORY property:
>
> * PROJECT make babel support org file links in header args (:file or :dir)
> :PROPERTIES:
> :CATEGORY: BabelLinks
> :END:
> ** TODO Finish the text prop org-mode
>
> Which would show in the agenda as:
>
> BabelLinks: TODO Finish the text prop org-mode
I hope that the above example gave enough context on why splitting a
task into sub-tasks is not always a good idea, even if you follow GTD.
However, what I described does not strictly require the functionality I
am requesting in this thread - we can as well directly modify the
headline.
Another situation when showing task-local context can be handy is when
the task is blocked by something (I am talking about concept of WAIT
tasks in GTD). In my example below, HOLD refers to task that I plan to
do as soon as it is not blocked by something else - equivalent of WAIT
tasks in GTD:
** HOLD Finish the text prop org-mode | make babel support org file links
In this example, note "Finish the text prop org-mode" refers to another
project, which I would like to focus on before starting the task.
Working on that org file links is "on hold" for now.
Seeing why the task is "on hold" is extremely useful when I do my weekly
review (as recommended by GTD). I can look at it and decide if the
reason the task is "on hold" is still valid or I can go ahead and mark
it NEXT.
One may argue that my example can be covered by task dependencies (via
org-edna). However, that is too restrictive in general case. Even though
initial reason why I put a task "on hold" is other higher-priority task,
I may, for example, be on vacation another week and thus have a time to
work on both tasks simultaneously instead of a need to focus on one
thing only. So, seeing the reason of putting "on hold" during weekly
review is important for me.
---------------
I hope the above examples explain why I suggested to implement the
new cookie type - it can be used in both the described situations.
> I have only been partially paying attention to this discussion thread, but
> this sounds like both a feature with limited appeal and significant
> complexity to implement, so I would suggest implementing it yourself for
> your own use case, and then bringing it to the mailing list to share. Once
> you have a dozen people using it, it will likely have developed into a
> mature enough form to include in Org mode.
I actually have working code showing the last note in agenda view. As I
described, I believe that such functionality can be useful. However, my
own implementation is limited to agenda (because I mostly use agenda).
If one prefers to browse org buffers directly, they will miss the
feature. Headline cookies should be more universal and also allow to
show the last note selectively, only in the headlines containing the
cookie.
The complexity only comes from the fact that we don't have formal
definition of "note".
> As a practical matter, I
> would find it inconvenient to have both the "last note take"/"next action"
> and the overall project headline appear in the agenta view because it makes
> the text too wide.
That's one of the reasons I propose to implement it as a cookie type.
You do not have to put [!] in your headline if do not want to.
Best,
Ihor
Allen Li <darkfeline@felesatra.moe> writes:
> On Sat, Aug 29, 2020 at 6:42 AM Ihor Radchenko <yantar92@gmail.com> wrote:
>
>>
>> Over the years of using Org I often have a need to add a short note
>> about how to proceed with some task:
>>
>> ***** REVIEW check again, subscribe | sindresorhus/awesome: 😎 Awesome
>> lists about all kinds of interesting topics :BOOKMARK:
>> :PROPERTIES:
>> :CREATED: [2020-03-15 Sun 18:59]
>> :Source: https://github.com/sindresorhus/awesome
>> :END:
>> :LOGBOOK:
>> CLOCK: [2020-03-17 Tue 16:18]--[2020-03-17 Tue 17:46] => 1:28
>> CLOCK: [2020-03-17 Tue 16:03]--[2020-03-17 Tue 16:18] => 0:15
>> - Refiled on [2020-03-16 Mon 23:59]
>> :END:
>>
>> In the above example, the short note is "check again, subscribe".
>> The note is not fixed, but changes as I progress with completing the
>> task.
>>
>
> Everyone has their own workflows, but I think the way you are approaching
> this problem is "wrong". Under the GTD methodology, there is the concept
> of a project (some higher goal to be achieved) and next actions (the
> concrete tasks to do next to achieve the project). You would only track
> the next action in your regular toto list. In Org mode, this would look
> like:
>
> * PROJECT make babel support org file links in header args (:file or :dir)
> ** TODO Finish the text prop org-mode
>
> My anecdotal impression is that many people using Org do this (see
> https://orgmode.org/worg/org-gtd-etc.html), so they have no need for a
> "last note taken embedded in headline" feature. As a practical matter, I
> would find it inconvenient to have both the "last note take"/"next action"
> and the overall project headline appear in the agenta view because it makes
> the text too wide. If I need to associate the next action with the overall
> project, I take advantage of the CATEGORY property:
>
> * PROJECT make babel support org file links in header args (:file or :dir)
> :PROPERTIES:
> :CATEGORY: BabelLinks
> :END:
> ** TODO Finish the text prop org-mode
>
> Which would show in the agenda as:
>
> BabelLinks: TODO Finish the text prop org-mode
>
> I have only been partially paying attention to this discussion thread, but
> this sounds like both a feature with limited appeal and significant
> complexity to implement, so I would suggest implementing it yourself for
> your own use case, and then bringing it to the mailing list to share. Once
> you have a dozen people using it, it will likely have developed into a
> mature enough form to include in Org mode.
>
> Just my 2 cents.
>
>
>> This is even more useful for delegated or HOLD tasks where I often need
>> to add a short note why the task is delegated or put on hold:
>>
>> ** HOLD Finish the text prop org-mode | make babel support org file links
>> in header args (:file or :dir)
>> [[id:468e0645-68aa-4e14-86de-e5ce153538e3][[2017-09-22 Fri]
>> CuNbARBshearstrength]] :HOLD:
>> :PROPERTIES:
>> :CREATED: [2020-07-20 Mon 16:53]
>> :SHOWFROMDATE: 2020-08-15
>> :END:
>> :LOGBOOK:
>> - State "HOLD" from "NEXT" [2020-08-10 Mon 15:16] \\
>> Finish the text prop org-mode
>> - Refiled on [2020-07-20 Mon 17:15]
>> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] => 0:01
>> :END:
>>
>> Seeing this note directly in the headline without a need to dig into the
>> task body / LOGBOOK drawer is really handy.
>>
>> In this last example, I had to duplicate the note taken using built-in
>> note mechanism into headline, which was inconvenient. It would be handy
>> if I could simply add a [!] cookie (similar to [/] or [%] cookies) to
>> the headline to show the last note taken for this task. Then, I could
>> easily see the reason why the task is blocked or what I am supposed to
>> do with the task right in agenda view or in the folded headline.
>> Something like the following
>>
>> ** HOLD [!] make babel support org... :HOLD:
>> :LOGBOOK:
>> - State "HOLD" from "NEXT" [2020-08-10 Mon 15:16] \\
>> Finish the text prop org-mode
>> - Refiled on [2020-07-20 Mon 17:15]
>> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] => 0:01
>> :END:
>>
>> The cookie would be replaced by the last note text, according to
>> user-defined format (say, "[%s] |"):
>>
>> ** HOLD [Finish the text prop org-mode] | make babel support org... :HOLD:
>> :LOGBOOK:
>> - State "HOLD" from "NEXT" [2020-08-10 Mon 15:16] \\
>> Finish the text prop org-mode
>> - Refiled on [2020-07-20 Mon 17:15]
>> CLOCK: [2020-07-20 Mon 16:53]--[2020-07-20 Mon 16:54] => 0:01
>> :END:
>>
>> What do you think?
>>
>> Best,
>> Ihor
>>
>>
next prev parent reply other threads:[~2020-09-06 1:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-29 6:40 [feature request] A new cookie type [!] showing the last note taken Ihor Radchenko
2020-08-30 8:50 ` Nicolas Goaziou
2020-08-30 10:40 ` Ihor Radchenko
2020-08-30 11:03 ` Nicolas Goaziou
2020-08-30 12:18 ` Ihor Radchenko
2020-08-30 12:57 ` Nicolas Goaziou
2020-08-30 14:58 ` Eric Abrahamsen
2020-08-31 2:26 ` Ihor Radchenko
2020-08-31 8:42 ` Julius Müller
2020-08-31 11:55 ` Ihor Radchenko
2020-08-31 14:58 ` Nicolas Goaziou
2020-09-02 2:02 ` Ihor Radchenko
2020-09-03 9:16 ` Nicolas Goaziou
2020-09-05 5:52 ` Ihor Radchenko
2020-09-09 14:00 ` Nicolas Goaziou
2020-09-10 9:24 ` Ihor Radchenko
2020-09-13 13:09 ` Nicolas Goaziou
2020-09-14 19:49 ` Eric Abrahamsen
2020-09-05 22:14 ` Allen Li
2020-09-06 1:23 ` Ihor Radchenko [this message]
2020-09-06 18:16 ` Eric Abrahamsen
2021-01-17 15:38 ` Christopher Miles
2021-01-18 2:07 ` Ihor Radchenko
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=87pn6zzoj7.fsf@localhost \
--to=yantar92@gmail.com \
--cc=darkfeline@felesatra.moe \
--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).