Re: [emacs-humanities] Paper Zettelkasten safety [was: Why Emacs-humanities?]

[Ihor Radchenko]

Jean Louis <bugs@gnu.support> writes:

> How do I display the list of tags in Org mode?

There is nothing like dashboard of tags in Org mode. However, you can
get a list of all the tags using (org-global-tags-completion-table).

> I have got the 2015 edition of Getting Things Done by David Allen. I
> just guess that about 10% of the book is pure hype and quotes by
> people who never had any method.

I guess that's a marketing trick. I never read those.

> I would say that one shall forget the GTD approach to capture
> everything and then sort in Trash, Someday, Reference, as it is
> useless waste of time:

It depends on what you mean by "everything". For GTD, "everything" is
literally everything:
 - something you need to do
 - random ideas (like "why Japanese cat's tails are short? Who is going
   to cut cat's tail and not being a madman?!")
 - bookmarks to be read later
 - email (including spam)
 - bills you get from grocery shop
 - advertisement flyers
 - funny items you noticed in a supermarket
 - strange smell you noticed while walking
 - etc

> - don't capture in first place what is Trash;

If you really capture everything, some things can really go to trash.
The easiest example is spam, which you anyway need to process as it is
"captured" for you in your email inbox. Or think of an advertisement
flyer you found at your home entrance - it is most likely trash, but you
may still look at it quickly to determine if it may have some actually
useful discounts.

> - sort notes and tasks where they belong; in my opinion any object can
>   be a reference, thus there is no need to think of "references"; 

I agree with you. However, GTD mostly says that reference is anything
that's not a task. Think of a utility bill you want to save in case you
need it. It is not a task, but you need to put it somewhere you can find
if you need to.

For me, done tasks can also be references. Or any other objects.
Basically, anything I may need to find later and may want to add tags.

Note that many done tasks don't really worth an effort adding tags.
Those can be trashed once done.

In my system, tasks can be references and non-tasks can be references.
The difference is only that a task, once done, has to be moved away into
archive or left within closer reach as it might still be useful in
future.

One example is book/article tasks. If an article is noteworthy, I always
add tags to it (as I read). Then, such article is saved within my
notes.org under appropriate topic. Otherwise, the article is archived
away into other file. The archived articles are not searchable by
default to avoid cluttering search results. I have many thousands of
articles discarded into archive and only several times less noteworthy
articles that I actually want to find from time to time.

> - if there is no time for the task to be done, it is task in
>   preparation or pending preparation, obviously not doable and not as
>   important; DO NOT SORT IT IN "SOMEDAY" -- rather break down the task
>   into more doable tasks. Find out WHY is it not doable and break it
>   down, make three doable tasks with time and then start doing! 

I think the question is not whether a task is doable in principle or
not, but rather if you want to do the task (or project) in near future
or not. For example, consider that you got an idea to learn how to play
chess gambits. That's an interesting thing to do, but you may not have
time for it in the following months. Then, there is not much point
thinking about details how to learn gambits. You better leave it for
future when you get free time or want to try some new hobby.

>   Sorting into "Someday" is procrastination. I see nothing to praise
>   there. If there is procrastination, don't even put it in any kind of
>   system, it is waste of time;

I do not agree that someday is useless. 5 years ago I stumbled upon
lecture series about human behaviour, but had no time to watch (it is a
full university course). 2 years ago, I decided to learn something I did
not know well and simply found this lecture series in my someday list. I
don't regret having that lecture link in my list at all. If I hadn't had
that list, I would otherwise spend free time on some more "default"
leisure activity, like playing computer games. Learning a bit of
neurobiology was a lot more meaningful and led me to interesting ideas
that are already helping my life.

Someday list is something I do not have to do. It is a list of ideas
that are better than "default" leisure that is most commonly occupied by
social media or other "time killing" activities.

>   Project writing is about setting goals, purposes, resources,
>   conditional targets, operational targets, production targets,
>   etc. And all that is written in such blazing manner that I don't
>   need even to stop. As when you start with purposes then you start
>   breaking down what has to be done to achieve that purpose.
>
>   Let us say you wish to defend from elephants when you are sleeping
>   50 meters from elephants' forest. If I don't know nothing about
>   elephans I have to start researching and asking people who know
>   <...>
>   ... Tasks do not come randomly to
>   form a project.

This is true if you know about elephants in advance. Then, you can
indeed plan for the defence when you are creating the project plan.
However, consider that you got to know that elephants often attack
people during certain season while talking to one of the contractors on
site. Then, you can note "research elephant aggression" and go back to
the talk. Later in the evening, you may look through your daily notes
(inbox) and think about this problem deeply, consult literature, create
a plan about what should be done, etc.

> ,----
> | The Value of a Bottom-Up Approach
> | 
> | I have discovered over the years the practical value of working on
> | personal productivity improvement from the bottom up, starting with
> | the most mundane, ground-floor level of current activity and
> | commitments.  Intellectually, the most appropriate way ought to be to
> | work from the top down, first uncovering personal and organizational
> | purpose and vision, then defining critical objectives, and finally
> | focusing on the details of implementation. The trouble is, however,
> | that most people are so embroiled in commitments on a day-to-day level
> | that their ability to focus successfully on the larger horizon is
> | seriously impaired.  Consequently, a bottom-up approach is usually
> | more effective.
> `---- by David allen
>
> I say that is incorrect and even mean. I even wonder how this goes
> through. One explanation I have, that it is popular, hype, and people
> speak about it. Like ponzi schemes, they were also popular.

I read the same section differently. As I understand it, David Allen
says here that we should not overspend time on high-level planning, but
also make sure that actual implementation of the plans becomes a routine
daily habit. Later in the section he writes:

>> Many executives I have worked with during the day to clear the decks of 
>> their mundane stuff have spent the evening having a stream of ideas and 
>> visions about their company and their future lifestyle. This happens as an 
>> automatic consequence of unsticking their workflow

In essence, this section of the book recommends to separate high-level
planning and implementation of the plans. Mixing the two things will
lead to procrastination: you may either bury yourself in mundane tasks
and loose the high-level goals or "fly in the clouds" thinking about the
future plans instead of implementing them.

> So up to 35th year he had 35 professions? 

I did not know this. However, I do not judge information _only_ by it's
original source. The method got popular for a reason. If the ideas are
meaningful, unreputable source does not matter [*]. In fact, I did not
really start my project planning efforts from GTD. I started from todo
lists without reading any literature on the topic. Then, I looked into
org mode articles and later other project planning references. GTD
popped up often, so I decided to look into the actual book only 2 years
ago - long after I started using (many) elements of GTD de facto:

**** Allen David [2015] Getting things done : the art of stress-free 
productivity :book:ATTACH:
:PROPERTIES:
:CREATED: [2019-07-02 Tue 20:06]
<...>
:END:

[*] https://www.lesswrong.com/s/3ELrPerFTSo75WnrH/p/5yFRd3cjLpm3Nd6Di

> Then: "Will it take less than 2 minutes?" -- that cannot be a rule to
> "delegate it". Delegation is always good in organizations, but
> decision making on delegation does not depend on time rather on
> authority, skills, area of responsibility. 
>
> If task is area of responsibility for communication officer, doing
> this task alone, regardless of what time is necessary is taking away
> responsibilities of that officer. It breaks organization. And again
> that officer would need to know about it. How would you feel as a
> postman who finds that your boss has delivered those letters which
> took just less than 2 minutes? Ah, come one. It is an nonsensical
> approach by David Allen who just found one of his 35 professions to be
> a self-help author and so he actually made it to be popular. Ego
> drives people high. 

Hmm. I agree that tasks taking less than 2 minutes may still need to be
delegated (even if delegation itself takes more than 2 minutes).
However, I find this example as an edge-case. More broadly, the idea is
to not postpone quick tasks for later. 2 minutes is just a rule of
thumb, not a rigid timescale. If you can do a task during review without
spending much time, do it. Otherwise, plan when to do it, how to do it,
and who is going to do it (i.e. delegate for other person, plan it for
certain time/date, or plan in for future when there is available time).

> Yes, keep doing it. If you find it good and perfect, keep doing. There
> is nothing wrong with people who keep using self-help books and
> improve their life.

I cannot say that I follow GTD book precisely. I haven't even finished
reading it :) However, the ideas I have read so far resonate with what I
am already doing and also gave me extra ideas to improve my workflows. I
recommend the book mostly because it provides a coherent system of
things I already know that they make sense. So, it may be treated as a
textbook. Yet, there are things that are missing (like reference/note
management) and things I am doing differently (I do not always separate
references from tasks).

> It is also good to know there is plethora of knowledge beyond one book
> of a man who has never got things really done in his life.

Sure. But do you know anything textbook-like describing project
planning? I know many web-articles describing various ideas, but not a
coherent text describing many aspects of project planning. Probably,
military planning guide you shared earlier may serve as such, but the
examples there are a too military-specific to be implemented in civilian
life without much efforts.

Best,
Ihor