zim-wiki team mailing list archive

[Svenn Are Bjerkem <svenn.bjerkem@xxxxxxxxxxxxxx>]

I enjoyed reading this mail, and I think that GTD is an interesting
topic. I have allowed myself to insert some comments that are based on
my own experience with GTD and other self-management techniques. With
me they mostly all fail because the applications are either java,
web-based or too hard to get the grip on. Take my comments as what
they are, comments. I really like Zim the way it is today and the way
it is moving as a desktop wiki. I fear that bringing too much GTD into
it will just distract from the main focus. If features are implemented
that would _support_ a GTD workflow on a general basis it is good, but
GTD is not the one-size-fits-all kind of problem.


2009/7/8 Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>:
> Hi,
>
> Below a description of how one can use zim to implement Getting
> Things Done. This is a direct result of the thread about the Getting
> Things Gnome application earlier. After that discussion I actually
> went to get a copy of the GTD book and did some thinking about how
> to structure my task lists. ( Not that this actually improved the schedule
> for releasing the python port of zim ... but I'm making good progress now
> and will make an announcement of current status soonish ... but I
> digress )

You should mayne also buy and read the book of Stephen Covey "First
things first", which also focus on getting things done, without using
that acronym. Many commons between FTF and GTD and some software tries
to combine them both. Most of them fail.

>
> This way of implementing GTD leaves a lot of freedom to the user,
> maybe to much freedom. If you like a task manager app to enforce
> some discipline this may not be for you. Still it may be useful.

I have read both GTD and FTF and too much freedom is not good for the
user who is trying to FTF or GTD if you read between the lines.
Anything free-form added may be lost unless you have an easy way to
force a perpetual link to the main thread.

>
> Please feedback any comments to improve content (I know style is
> still lacking - of course help rewriting is also welcome). My intention
> is to include this in the manual as an example on how you can use
> zim.

Suggest to put it as a use case of Zim as you would otherwise discover
that a lot of GTD people will ask you to implement this and that and
make this and that more rigid and then suddenly you are writing yet
another GTD and will loose users who tried and failed GTD.

>
> All the way at the bottom I give some ideas for improving zim to
> allow better task management in the notebook. But keep in mind when
> that zim is not intended to be a full fledged task manager.

Wiki is free flow text and task management is fixed flow text (unless
you implement templates that can be updated and automatically updates
all pages using that template in order to have a well defined page
format for each task. No wiki that I have used so far has been able to
post-impose template formats on existing pages). In my opinion, you
can't have one foot in each camp.

> ====== GTD ======
>
> The GTD methodology basically calls for maintaining lists of all loose
> ends that need be taken care of. The idea is that when all things that
> need to be done are recorded on a list it will give you peace because
> you do not have to keep them in your mind all the time. However it is
> essential that you can access the lists in and sort through them so
> you always know what the next thing is that you can do given the time
> and tools available at a certain moment.

Take a simple bulleted list in a page. You must be able to move list
items and their siblings up and down the list with keystrokes as
people tend to have the important list items at the top. Items must
also have the possibilities to be indented with their parents. The
printing possibilities must be improved as the HTML output of my pages
do not look the same indentwise as in my Zim workbooks.

>
> For those not familiar with the book either read it or check any of
> the  numerous websites discussing it. Would like to include the
> general flowchart from the book here but this is of course
> copyrighted. But go check google image search for any of numerous
> online copies.

The flowchart has been reproduced in so many other GTD applications so
if you simply redraw it you won't affect any copyright. He didn't
patent the idea as far as I know.

>
> ==== How I implement GTD in Zim ====
>
> First create a new notebook to be used specific as a task tracker.
> Create namespaces for the various categories. I use "Projects",
> "SomeDay" and "Archive" for current, incubating and dormant projects.
> There are two special pages, one called "INBOX" which is a generic
> dump for incoming stuff and one called "Chores" (which is in the
> projects namespace), this is a generic list of tasks that do not
> belong to any particular project.

The way I understood GTD, someday are projects. It is just that they
are not in current focus. It is not forbidden to plan a someday
project completely with dos and donts. When that someday occures, it
is put into life and finished. You should just not get someday
projects in your face when you are looking for possible next actions
for the next 10 minutes.

>
> I also have several pages living in the top level of the notebook with
> various lists. These do not contain tasks. For e.g. there is a list
> there with books I have on loan or have loaned out to other people and
> there is a list birthday present ideas. If you have many of these
> lists consider putting them in a "Lists" namespace. Important is that
> a list does not contain tasks.

I consider this wrong interpretation of GTD as having a task with
anything should be possible, it is just that they do not show up until
the parent item is activated to get done. The key of GTD is to get
things out of your head and into the system as soon as they show up to
free your mind for the real next actions. If getting a book back from
Tom implies buying a baseball bat, then that should be listed as a
task related to the fact that you have lent a book to Tom. When the
due date for the book is out, it will show up in your next action as
"Time is due to go get a baseball bat and visit Tom" :-)

>
> Now for more complex sets of tasks, or projects each has it's own page
> below the "Projects" namespace. It can have any number of children
> with information that relates to this particular project and can have
> tasks all over the place. Some items start out as a project from the
> start, others first live as a bunch of related tasks on the "Chores"
> page until they take up to much room and get moved out to their own
> page.

If you want to drop TODOs all over the place, then the TODO search
mechanism must have the possibility to go to that TODO on that page
when it is highlighted in the TODO dialog. Currently it only takes you
to the page, and then the user has to look for it on that page.

>
> To define individual tasks I use checkboxes. This forces the main
> description to be a single line, which is good to make sure each task
> clearly states a physical action. Of course just below the checkbox
> their can be a whole paragraph or even many sub-pages with all the
> details. If the description sounds more like a topic than like an
> action most likely it should be divided in smaller items that are
> actions.

As far as I can see from usage of Zim, it is not easy to indent the
baseline of text. If you want a listbox to be the headline of a task
description, then this description must be entierly indented at least
one level compared to the task title

[] Buy a baseball bat
        Tom is a good friend but when it comes to delivering back
        books, he understand no jokes. He thinks everything within
        his house is his property and must be convinced otherwise.

>
> These task line items can have tags like "@work", "@home" etc. which
> will allow you to filter them more easily in the task overview. Also
> you can use the tag "@waiting" for tasks that you need to check on but
> are now waiting on someone else to take action.

@waiting(for) should according to GTD  be a namespace within the
namespace as you can have things at home which is waiting for and
things at work which is waiting for, and when you are in one of the
namespaces (@work, @home) the waiting fors of the other namespaces
should not clutter your view except at end of the week when things are
summarized.

>
> Also task line items can have a due date, which will show up in the
> task list. But I do not use this - timing changes all the time anyway.
> Priority can still be assigned using "!", but don't over-use it, prios
> are shifting all the time anyway as well. Only use it for things that
> need to be done ASAP to feel comfortable again.

I found due dates useless, too. What I do in Zim is to put the date
when I entered the TODO line or ckeckbox. That way I can sort todos to
find out which items have been neglected for a long time. The use of !
as a priority level is in my opinion not good in the first place. If I
print my lists to give them to my boss, he does not understand that.
He understands priOne, priTwo and maybe priThree. Anything else is
lowPri. Things like urgent, immediate etc. doesn't mean anything to
management. Everything is urgent. Question is what you are working on
right now. If you want to implement GTD you should make it usable in a
work place as this is where people really have to GTD. That is also
the main message of the David Allen. Also keep in mind that the
computer is not always available. A quick printout in a Hipster PDA
format would be nice for things done where a computer is not
available.

>
> Now to get an overview of all the tasks that can be done I open the
> TODOList plugin and check the "include all open checkboxes" option.
> This will show a flat list of the tasks defined throughout the
> notebook and sorts by priority. One can filter on keywords or tags.
>

Dangerous, tags are often forgotten if the user has to type them.
Besides the user should not get @home things when he is @work and vice
versa. That will only distract.

> Projects that are still under incubation, so I collect ideas, but no
> action yet, live under the "SomeDay" namespace. These do not contain
> any tasks - as soon as they do they should move to the "Projects"
> namespace. Projects that are finished, abandoned or on hold should go
> under the "Archive" namespace. These should not contain any open tasks
> as well. If there are any open tasks when I move a project there I
> check them off with the [x] checkbox to show they will not be done.

Archive is for things that are finished or used for reference
(commenting referenced files is one of the major advantages of zim).
Projects on hold is not archive. They are someday. They still live
since they are not finished. Abandoned projects should be deleted if
they do not have any reference value. If they have some value, they
are someday, if you will never touch them again, they should be
deleted. It's like keeping that pile of trade magazines on your desk
just because you maybe need an article. Copy the article, put it in a
physical folder, and throw away the magazine. (That is also what Allen
says: keep only what you need, throw away the rest) This implies that
the someday will soon be filled with things not useful to anybody,
otherwise archive will be filled with useless orphaned information.

>
> As an extension I also use the Calendar plugin to have a journal page
> for each day with notes from meetings etc. Action items from meetings
> may live there, but this usage is a bit at odds with the use of the
> INBOX page. At least I can reference discussion notes of a certain
> date from a project page etc.

If the Calendar can consolidate all notes on a specific project at any
time this will be nice. I am afraid of loosing jots put into the
calendar. I like the idea of putting things I do on one day onto a
page representing that date, but when I am asked when I put a new
feature into any code of any project, then I need to quickly get a
list of all notes for that project only. No other items should
intermix. Action Items must be treated specially so that it is
guarranteed that they will never ever get lost. The TODO item works
very well if the due date is replaced with the entered date, but an
ACTION item cannot be a TODO item as ACTIONs are a different type of
item.


Another thing, the DELEGATED type is missing. Could be a waiting for,
but maybe I am not waiting for it to be finished. My boss is waiting
for it to be finished, but not by me. I just need to know that
something has been given to somebody else in case my boss has
forgotten and suddenly pops into my office and asks questions.

>
> === Summary ===
> • Each action belongs to an open project - "Chores" is the collection
> bucket for small tasks
> • Open projects go in the "Projects" namespace
> • Open projects should have a clearly defined goal which can be
> evaluated and stamped "finished" at a certain point in time
> • Otherwise they go in either "SomeDay" or "Archive"
> • Each action should have a checkbox - possible follow up actions can
> have normal bullets if they are not actionable yet
> • Tags on action are used to generate lists
> • Some tickler lists can have their own pages, like "Loans"
>
> === Possible improvement for the TODOList plugin ===
> 1. Rename to TaskList plugin
> 2. Add side pane in the TODO list showing tags -> patch committed,
> available from launchpad
> 3a. Distinguise a tree view, showing hierarchy of checkbox lists and
> page, and a list view only showing outer branches which represent
> actionable items
> 3b. Configure a special tag for items that are waiting (like @waiting)
> and use this to filter actionable items
> 4. Make items directly editable from the TODOList dialog

It was mentioned in another thread to make Zim more mind-map friendly.
A lot of the mind-map features are needed with task management. (GTD
is about getting tasks done) If features are implemented that support
these workflows, that can only be good for other ways of using zim as
most features are about moving data around and keeping links. I think
the most important basic features like multiple faces on text is more
important. Mixing italic and bold in a text is not possible today.
Changing color of parts of text to emphasize (or grey10 to
de-emphasize without strike-through) is not implemented. Printing from
zim is not happy. The print to browser function garbles up indentation
of non-bulleted text. Tables are missing (sometimes they are useful)

I am probably asking for too much without the possibility to give much
useful back but bear over with the soar comments as I still find zim
the currenly best solution to my problem of organizing my archives of
experience.

Kind regards,
-- 
Svenn