diff options
| author | Lars Wirzenius <liw@liw.fi> | 2023-10-31 19:40:35 +0200 |
|---|---|---|
| committer | Lars Wirzenius <liw@liw.fi> | 2023-11-06 08:57:20 +0200 |
| commit | bfb56ad43fb63f46dc247e6d5382fdeb1e4772cd (patch) | |
| tree | c5c382638c1c8989bd4e06eca64fc27a5b296a02 | |
| parent | ca00525a42de0fc909becc68a677cd6a167a856d (diff) | |
| download | gtdfh.liw.fi-bfb56ad43fb63f46dc247e6d5382fdeb1e4772cd.tar.gz | |
rewrite the whole site
Signed-off-by: Lars Wirzenius <liw@liw.fi>
Sponsored-by: author
| -rw-r--r-- | .ambient.yaml | 3 | ||||
| -rw-r--r-- | .gitignore | 3 | ||||
| -rw-r--r-- | Makefile | 34 | ||||
| -rw-r--r-- | automation.mdwn | 30 | ||||
| -rw-r--r-- | book.xml | 5 | ||||
| -rw-r--r-- | calendars.mdwn | 64 | ||||
| -rw-r--r-- | conclusion.mdwn | 18 | ||||
| -rw-r--r-- | cover.png | bin | 42749 -> 0 bytes | |||
| -rw-r--r-- | cover.svg | 109 | ||||
| -rw-r--r-- | daily-routine.mdwn | 29 | ||||
| -rw-r--r-- | doing.mdwn | 54 | ||||
| -rw-r--r-- | files.mdwn | 128 | ||||
| -rw-r--r-- | getting-started.mdwn | 98 | ||||
| -rwxr-xr-x | git-mtime.sh | 11 | ||||
| -rw-r--r-- | gtdfh.css | 19 | ||||
| -rw-r--r-- | ikiwiki.setup | 37 | ||||
| -rw-r--r-- | inboxes.mdwn | 171 | ||||
| -rw-r--r-- | index.mdwn | 621 | ||||
| -rw-r--r-- | introduction.mdwn | 108 | ||||
| -rw-r--r-- | journalling.mdwn | 51 | ||||
| -rwxr-xr-x | list-chapters | 6 | ||||
| -rw-r--r-- | local.css | 5 | ||||
| -rwxr-xr-x | markdown-to-pdf | 44 | ||||
| -rw-r--r-- | person.mdwn | 4 | ||||
| -rw-r--r-- | projects-next-actions.mdwn | 180 | ||||
| -rw-r--r-- | quickie-overview.mdwn | 32 | ||||
| -rw-r--r-- | read-and-review.mdwn | 60 | ||||
| -rw-r--r-- | references.mdwn | 7 | ||||
| -rw-r--r-- | review.mdwn | 80 | ||||
| -rw-r--r-- | sidebar.mdwn | 14 | ||||
| -rw-r--r-- | someday-maybe.mdwn | 20 | ||||
| -rw-r--r-- | ungood.mdwn | 63 | ||||
| -rw-r--r-- | waiting-for.mdwn | 55 |
33 files changed, 634 insertions, 1529 deletions
diff --git a/.ambient.yaml b/.ambient.yaml new file mode 100644 index 0000000..659fe97 --- /dev/null +++ b/.ambient.yaml @@ -0,0 +1,3 @@ +kind: ikiwiki +image: ~/tmp/ambient/ikiwiki.qcow2 +source: . @@ -1,2 +1 @@ -.ikiwiki -book.* +*.html @@ -1,24 +1,16 @@ -chapters = $(shell ./list-chapters index.mdwn) +SHELL = bash +TARGET = _ewww@web:/srv/http -all: book.pdf book.epub book.mobi +all: gtdfh.html -book.pdf: $(chapters) - pandoc -V geometry:a4paper --top-level-division=chapter \ - --toc -o book.pdf $(chapters) +gtdfh.html: index.mdwn gtdfh.css Makefile + pandoc -f markdown+implicit_figures --toc --self-contained -N \ + --metadata title="GTDFH" --metadata subtitle="Getting Things Done for Hackers" \ + -H <(echo "<style>"; cat gtdfh.css; echo "</style>") --standalone index.mdwn -o gtdfh.html -book.epub: $(chapters) cover.png - pandoc -t epub --epub-metadata=book.xml --epub-cover=cover.png \ - -o book.epub $(chapters) - -book.mobi: book.epub - ebook-convert book.epub book.mobi - -cover.png: cover.svg - inkscape -e cover.png cover.svg - -count: - wc -w $(chapters) - echo 100 '*' $$(cat $(chapters) | wc -w) / 30000 | bc -l - -clean: - rm -f book.pdf book.html book.epub book.mobi cover.png +publish: all + mkdir publish + cp -a gtdfh.html publish/index.html + cp gtdfh.css publish + rsync -a --del publish/. $(TARGET)/. + rm -r publish diff --git a/automation.mdwn b/automation.mdwn deleted file mode 100644 index e22e1bd..0000000 --- a/automation.mdwn +++ /dev/null @@ -1,30 +0,0 @@ -Automation and checklists -========================= - -Hackers know how to program, and so can fairly easily automate anything -that happens on a computer. This can be a great time saver. It can also -be a great time waste. If something takes a lot of time and effort to -automate, but doesn't actually take much time to do by hand, then it's -probably not worth it. However, in many cases spending an evening to -write some scripts to automate something is worthwhile not just to -save time, but to not ever have to do it again. For example, instead -of filling out timesheets by hand at work, writing a script that does -them automatically based on the work laptop's suspend/resume logs, -plus git commit timestamps, may not actually save much effort, but -not having to deal with the bureaucracy can save you from a fate -worse than ennui. - -Some things are possible to automate even without being able to -program. For example, paying bills via direct debit, or putting -money into a savings account by a standing order, can both make -dealing with money much easier. - -For things that can't be automated (or which aren't worth the -development effort for the AI), but you do repeatedly, it can be -worth writing a checklist. Especially things you do less than once -a week, or which you absolutely have to get right every time, a -checklist can help a lot. The mere process of writing the checklist -forces you to consider and review the process. When you're actually -doing the task, especially if it is urgent or stressful, it can be -nice to not have to think about each step every time you do the task. - diff --git a/book.xml b/book.xml deleted file mode 100644 index 8e48fca..0000000 --- a/book.xml +++ /dev/null @@ -1,5 +0,0 @@ -<dc:title>Getting Things Done For Hackers</dc:title> -<dc:creator>Lars Wirzenius<dc:creator> -<dc:language>en</dc:language> -<dc:identifier id="f0899b66-7b39-11e1-8440-001f16157bd8" /> - diff --git a/calendars.mdwn b/calendars.mdwn deleted file mode 100644 index b9d2e88..0000000 --- a/calendars.mdwn +++ /dev/null @@ -1,64 +0,0 @@ -Calendars and other reminder systems -==================================== - -Some things in life have to happen at particular times. For these, -the calendar is the perfect tool. Any kind of calendar will work, -as long as you use it diligently for this kind of thing: paper -or digital, pocket or wall, or even just a text file with dates. - -Calendar software has some features that make them particularly useful -for many people: group calendars, ease of separation between personal -and work calendars, etc. - -You already know how to use a calendar for its basic tasks, so we -won't go into that. - -You can use calendars as an inbox as well. For example, if you need -to start working on a project in September, but don't need to worry -about it before that, then adding a reminder about the project on -September 1 will work fine, but only if you treat the calendar -as an inbox. If you use a digital calendar, you can have one for -these inbox items in particular. - -Automatic nagging systems -------------------------- - -Another kind of thing is stuff that needs to happen regularly. For -some of these, digital calendars are still the tool of choice: you -could add a bi-monthly reminder to get a haircut to your calendar, -for example. If you get the timing right, your calendar will remind -you just before your partner does, and you'll both be saved an -unnecessary discussion. - -Calendar reminders may also be replaced or augmented by cron jobs, -which run, for example, on the Monday before the second Thursday -of each month, and tell you to send out an invitation to the -monthly meeting, which happens on the second Thursday each month. -Whether you use an actual calendar, or a cron job, is your choice, -of course: use the tools that suit you best. - -Cron jobs have the advantage over calendars that they can be -conditional: a cron job could, for example, see if you've already -sent out the invitation, and not remind you if you have. - -Some stuff does not fit so easily with calendars. For example, -suppose you want to cut your nails when they get too long, but you -keep getting distracted by your computer so that it may take you a -month to notice that it's time to cut them. And when you do, it's -because you break a nail, which is a bit painful. After some experimentation -you decide that twelve days after the previous time is a good time to -cut your nails. Having your computer remind you about it makes it -much more likely that you'll do it when it's time. However, having -your calendar remind you every twelve days may not work so well, -because you might be travelling on that 12th day, and the annoying -flight security theater made it impossible to take your nail cutter -with you. (This is not a hypothetical example.) - -A better solution would remind you twelve days after -the previous time you actually cut the nails, not after the previous -reminder. I have a program called "nagger" which does exactly that, -but it is not suitable for others to use (unless you dig editing -`procmailrc` files, and probably not even then). The nagger remembers -when you last did something, and after the specified time, it -starts nagging you every day until you tell it you've done it again. - diff --git a/conclusion.mdwn b/conclusion.mdwn deleted file mode 100644 index 2405f07..0000000 --- a/conclusion.mdwn +++ /dev/null @@ -1,18 +0,0 @@ -Conclusion -========== - -Do stuff. -Be happy. - -A word of warning ------------------ - -It's easy to get too interested in GTD. Initially, it's natural and -expected that you'll spend some time trying out different ways of -doing things, and various tools and approaches and so on. However, -this should not become a primary occupation. The goal is not to have -GTD as a hobby, since that'll just get in the way of actually doing -useful things. - -The irony of the previous paragraph being written by someone who -wrote a booklet about GTD is duly noted. diff --git a/cover.png b/cover.png Binary files differdeleted file mode 100644 index 117933f..0000000 --- a/cover.png +++ /dev/null diff --git a/cover.svg b/cover.svg deleted file mode 100644 index 19f8f47..0000000 --- a/cover.svg +++ /dev/null @@ -1,109 +0,0 @@ -<?xml version="1.0" encoding="UTF-8" standalone="no"?> -<!-- Created with Inkscape (http://www.inkscape.org/) --> - -<svg - xmlns:dc="http://purl.org/dc/elements/1.1/" - xmlns:cc="http://creativecommons.org/ns#" - xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" - xmlns:svg="http://www.w3.org/2000/svg" - xmlns="http://www.w3.org/2000/svg" - xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" - xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape" - width="744.09448819" - height="1052.3622047" - id="svg2" - version="1.1" - inkscape:version="0.48.3.1 r9886" - sodipodi:docname="cover.svg" - inkscape:export-filename="/home/liw/gtdfh.branchable.com/cover.png" - inkscape:export-xdpi="89.660004" - inkscape:export-ydpi="89.660004"> - <defs - id="defs4" /> - <sodipodi:namedview - id="base" - pagecolor="#ffffff" - bordercolor="#666666" - borderopacity="1.0" - inkscape:pageopacity="0.0" - inkscape:pageshadow="2" - inkscape:zoom="0.49497475" - inkscape:cx="13.365389" - inkscape:cy="514.28571" - inkscape:document-units="px" - inkscape:current-layer="layer1" - showgrid="false" - inkscape:window-width="1280" - inkscape:window-height="741" - inkscape:window-x="0" - inkscape:window-y="27" - inkscape:window-maximized="1" /> - <metadata - id="metadata7"> - <rdf:RDF> - <cc:Work - rdf:about=""> - <dc:format>image/svg+xml</dc:format> - <dc:type - rdf:resource="http://purl.org/dc/dcmitype/StillImage" /> - <dc:title /> - </cc:Work> - </rdf:RDF> - </metadata> - <g - inkscape:label="Layer 1" - inkscape:groupmode="layer" - id="layer1"> - <rect - style="fill:#dcdcdc;stroke:#000000;stroke-width:11;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;fill-opacity:1" - id="rect3024" - width="733.37073" - height="1040.4572" - x="8.0812206" - y="7.8644514" /> - <text - xml:space="preserve" - style="font-size:72px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:DejaVu Sans Mono;-inkscape-font-specification:DejaVu Sans Mono" - x="151.42857" - y="243.79076" - id="text2985" - sodipodi:linespacing="125%"><tspan - sodipodi:role="line" - id="tspan2987" - x="151.42857" - y="243.79076">Getting</tspan><tspan - sodipodi:role="line" - x="151.42857" - y="333.79077" - id="tspan2989">Things</tspan><tspan - sodipodi:role="line" - x="151.42857" - y="423.79077" - id="tspan2993">Done</tspan><tspan - sodipodi:role="line" - x="151.42857" - y="513.79077" - id="tspan2997">for</tspan><tspan - sodipodi:role="line" - x="151.42857" - y="603.79077" - id="tspan2999">Hackers</tspan><tspan - sodipodi:role="line" - x="151.42857" - y="649.93378" - id="tspan3814" - style="font-size:28px">(2012-06-17c)</tspan></text> - <text - xml:space="preserve" - style="font-size:72px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:DejaVu Sans;-inkscape-font-specification:DejaVu Sans" - x="148.57143" - y="749.50507" - id="text3001" - sodipodi:linespacing="125%"><tspan - sodipodi:role="line" - id="tspan3003" - x="148.57143" - y="749.50507" - style="font-size:48px">Lars Wirzenius</tspan></text> - </g> -</svg> diff --git a/daily-routine.mdwn b/daily-routine.mdwn deleted file mode 100644 index eed4e1b..0000000 --- a/daily-routine.mdwn +++ /dev/null @@ -1,29 +0,0 @@ -The daily routine -================= - -There's things you do every day: get up, take a shower, check your -e-mail, etc. This is pretty much automatic, and requires no particular -attention. Having routines is good, since it relieves you from having -to make decisions all the time about trivial stuff. (It's also good to -break your routines every now and then, to avoid boredom.) - -Some stuff is worth having a checklist for. For example, I need to -take medicine daily, so my daily checklist has an item for that. Regardless -of how good your memory is, it's easy to miss something small like that. - -Having a cron job that mails you the checklist daily is one excellent -way of reminding yourself about the things you need to do every day. - -My daily checklist has these things: - -* Weigh. -* Take morning pills. -* Check that phone is charged and that ringer volume is suitable. -* Do morning exercises (mark in exercises.gnumeric). -* Check calendar. -* Check all inboxes. -* Update Journal. -* Sync version control repositories. -* Run laptop backups. -* Train with Mnemosyne. - diff --git a/doing.mdwn b/doing.mdwn deleted file mode 100644 index c86e34d..0000000 --- a/doing.mdwn +++ /dev/null @@ -1,54 +0,0 @@ -Actually doing things -===================== - -This is what it's all about. Everything else exists just to support -this bit: actually doing the things you need to do. - -Doing is usually easy when it's clear what you need to do (a -well-defined next action), -and you have all the things you need for doing it (proper context), -and the motivation to do it. If you've got your GTD system working -smoothly, but things still don't get done, the problem is usually -motivation, or at least that's the big problem for me. - -Sometimes the problem is that the next action is defined vaguely: -it's not actually clear what you need to do. Perhaps it was clear -when you were planning it, but you didn't write down enough details -to remember later why you need to do it, or exactly what needs doing. -"Call Clara's cell" may be what you wrote down, but you can't remember -which Clara, and whether to call her mobile phone or the jail? You -need to describe next actions with enough information that you don't -have uncertainty. - -Sometimes it's because the thing to do is unpleasant, or boring. -I have no good solution for that, except to grow up. (I'll be doing -that any decade now.) I myself have a habit of skipping over next -actions that I don't particularly enjoy, with the result that they -may hang about for months in my next actions list. I'm also very gullible -so when I tell myself that they've not been there for very long, I -believe myself. That's why I put a date (at least year and month) on -every next action, so I don't believe my own lies. - -Update: One thing that seems to work for me is to find the tiniest -little part of the unpleasant thing that needs doing, and do that. -Repeating that a few times is usually enough to break the blockage. -For example, if the unpleasant thing is "wash the toilet bowl", the -tiniest few things might be "locate the toilet brush", "locate the -disinfectant", and "find rubber gloves". - -After you've done something ---------------------------- - -When you're finished with a next action, you can delete it from your list, -or cross it over, or otherwise mark it as done. This can be a very -satisfying feeling. - -Instead of deleting, you may also want to move the item from your -next actions list to a list of finished stuff. Such a log can also -be quite satisfactory to read, later on. I've found that deleting -things gives me more pleasure, though, and I keep track of what I've -done using a journal instead. - -I also write summary entries in my journal of things that I've done -or that have happened, as part of my weekly review. - diff --git a/files.mdwn b/files.mdwn deleted file mode 100644 index ffa15ae..0000000 --- a/files.mdwn +++ /dev/null @@ -1,128 +0,0 @@ -Keeping track of files -====================== - -There are two kinds of files you need to keep track of: those related -to current affairs, and those you archive for possible future use. These -have different usage patterns, and may need different kinds of handling. - -Current files (also called "pending and support") are for active projects. -You may need to access these files at a moment's notice, so they should -be at hand. - -Archived files are needed rarely, possibly never. Access times may be -longer, but it should still be easy to find them. An archive is useless -unless you can find things from it when you need them. - -Files may be digital or on paper. You may have current files on your -computer, and on paper, and ditto for archived files. This might not -affect the way you organize them: much of the organization is dependent -on naming and sorting, and it is probably best to use the same naming -system for both digital and paper files. - -You may have other things than documents you need to keep track -of for some of your projects. For example, one of your projects might -be to move some artwork to a different country, and the artwork would -then be part of your current files. Since large paintings are hard -to keep on your desk, never mind risky, you may want to represent -them in your GTD system using proxies: instead of putting each painting -in your "current files" folder, you can put a photo of the painting -there instead, and store the actual artwork somewhere safe. - -There are any number of ways in which papers and computer files -may be organized. For example, Allen recommends using manilla folders -for papers, and dislikes hanging folders; others like hanging folders. -If nothing else, hanging folders seem to be easier to find in at least -some European countries, whereas manilla folders are considered an -exotic American delicacy, which cost a premium. - -Some people reject both kinds of folders, and use ring binders. -Or envelopes. More important than the physical manifestation of -the concept of "folder" is how you arrange them, when you have many -of them. - -What seems to work best for me is to have an easy, cheap way to -have very specific folders (envelopes, tabs in ring binders, whatever). -Each folder should have very specific kinds of items in it. Thus, -a folder named "Edinburgh council tax, 2011" would be better than -"Financial stuff". The former is very specific, the latter would -quickly grow to be unhelpfully large. - -Every folder should be labelled clearly. People with a lousy -handwriting font might want to invest in a label writer of some -sort, so that the folders can be labelled in a readable fashion. -However, clear handwriting, if you have it, works fine too. - -Allen recommends a simple alphabetical sorting system for -folders. Others like two or three levels of keywords. Thus, the -tax folder from above might instead be called "2011, tax, council, -Edinburgh" or "UK, Edinburgh, council tax, 2011". The order of -the keywords depends on how you're most likely to search for them: -put the year first, if you think of things mainly in chronological -order. Put the location first, or the words "council tax" (or "tax, -council") first, if those are what you look for first. Whatever -works for you is best. - -You'll eventually gather a fair number of folders, so putting some -thought into your naming scheme ahead of time helps a bit. However, -if you've never done this kind of thing before, be prepared to -re-do it at least once. ("Be prepared to write a prototype, since -you'll make one anyway.") - -For digital files, having a computer that can quickly do full text -searches helps a lot. Indeed, you may be tempted to rely on search -only, and if that works for you, great. However, there are files for -which full text search won't work, such as images, audio, and video. -Thus, it is probably best to put your digital, archived files in -folders named using the same system you use for your paper files. - -I recommend having a folder named "Archive" (or something similar -in your local language), which is the location where all your archived -files shall be. Under "Archive", you'll create a folder for each -topic: these are the folders that correspond to the physical manilla -folders (or equivalent). Have only one level of these. - - $HOME/Archive/ - Council tax 2011/ - Debian DPL plans/ - Orange GSM prepaid/ - Talk: Debconf 2010/ - Three GSM prepaid/ - -Having only a single level of archive folders makes it easier to -look for them manually, when full-text search is not available or isn't -good enough. If you create folders within folders, searching manually -becomes at least an order of magnitude harder. - -Create a folder under "Archive" even if you're only putting a single -file there. Later you might need to archive a second file together -with the first one, and if you didn't create the folder beforehand, -you'll have to move the first file. - -The archived files should be left undisturbed. Do not modify them in -the archive. If you need to start changing them, move them out of the -archive first, into your current files. It's OK to read from the -archive, but not change them. - -Scanners and shredders ----------------------- - -Paper is big and heavy and hard to grep through. Scanning everything -you put into your paper archive makes it possible to carry it with -you on your laptop, and often makes it much faster to find a particular -item, particularly if you can get OCR to work so that your scans result -in text rather than images. Further, you can more easily make backups -of your digital documents than of your physical ones. - -Scanning everything also often gives you the option of shredding or -recycling stuff you don't actually need in hardcopy. This is even -better, since it allows you to reduce the size of your physical archive. -That, in turn, means it takes up less space (reducing living costs, -since you can have a smaller home), and makes it easier to move. - -However, before you shred, be sure you do not need the physical copy. -In some countries, tax authorities require the original physical -document or receipt, for example. - -Many devices come with manuals in many languages. Often it is possible -to find a PDF of the manual from the manufacturer's website, allowing -you to get rid of the bulky manual. diff --git a/getting-started.mdwn b/getting-started.mdwn deleted file mode 100644 index 2f891a7..0000000 --- a/getting-started.mdwn +++ /dev/null @@ -1,98 +0,0 @@ -Getting started -=============== - -You've read all about the GTD system, and you've decided to go for it. -Now what? - -There's at least two approaches for getting started. The one I did was -to start big. I allocated a whole weekend and did nothing else than -kickstart my GTD system. I cleared my kitchen table to use as a giant inbox. -I collected every bit of paper, every unopened letter, every unread book -and magazine, every appliance that needed fixing, and everything else that -I needed to do anything about, and put them on the table. - -[[!img first-inbox.jpg alt="My first inbox: the kitchen table"]] - -When I found large items that were too big for the table, I wrote down -what it was, where it was, and what I needed to do about it, on a separate -piece of paper, and put that on the table instead. A proxy like this is -as good as having something in your inbox, when the thing is cumbersome. - -After that, I took several A4 pieces of paper, and titled them "Next actions", -"Projects", "Someday/maybe", and "Waiting for". These were my lists. I -decided to start with pen and paper, rather than a fancy sofware solution, -to avoid getting distracted by technology. Pen and paper is about as simple -and reliable and uncomplicated as you can get. When you start your GTD -system, keeping it simple means you're more likely to make it work. You can -try complicated tools later, but initially avoid the trap of getting lost -in finding and selecting optimal tools. - -Then I started processing the inbox table. I picked the topmost item, -and thought about it, and decided what to do. A lot of things went straight -into recycling or garbage, which was nice: I no longer needed to have -them in my life at all, and this made me feel better. Any stuff that I -had lurking about was stuff that potentially demanded attention from me, -and even if it only actually did that once a year, with a thousand unnecessary -things, that's three things per day. - -Other things went into my lists. In fact, most things went into my lists. -During that first weekend, I did not actually do anything much. I did a -few very quick things, such as throw away rotten fruit, but otherwise I -suspended the two-minute rule. - -After I'd cleared the table, I did the same thing with my computers. I -collected all my files and e-mails and bookmarks and so on into one -digital inbox per computer, and then processed those. I still kept all -my lists on paper, though. As it turned out, my digital life was in much -better order so there were rather fewer next actions and projects generated -from that. - -By Sunday evening all my inboxes were clear, and my lists were long. -It was somewhat depressing to have so many things in my lists, but it -was a huge relief to know that everything I needed to be on them, were -on them. - -Over the next few days and weeks I tackled the lists, doing things and -sometimes deciding to uncommit myself from things, to get the lengths of -the lists under control. - -The slow start --------------- - -A big start may require you to put everything else on hold for a day or -several days. A gentler, but possibly less efficient way to start is -to go slow. Set up an inbox and the lists. Whenever you have time, go -through some of your stuff and put anything you haven't already processed -into the inbox, or process stuff already in your inbox. This can be -much harder to do than the big start, since you need to keep track of -what has and what hasn't been processed yet, but it also means you can -continue to function normally while you do it. - -You might start with just one aspect of your life. For example, start -with your e-mail only. Or your non-electronic mail. Or anything to do -with work, or your studies, or whatever. Then expand your GTD system -with time to cover more of your life. - -Survival strategies -------------------- - -Sometimes you have so much unprocessed stuff in your life that you feel -you're drowning under it. For example, you might have an e-mail inbox -that's several thousand mails long, and you feel you're not ever going -to be able to deal with it, there's just not time. - -You can deal with it by either giving up, or by taking a long time. -Some people have declared an e-mail bankruptcy, where they announce -that they've deleted their entire inbox, and if anyone had anything -important they should re-send. This may or may not be a good idea, but -it does give you a clean slate to start from. - -An alternative is to create a new folder, and move everything from -your inbox into that. You'll get to everything in there eventually, -but keeping your actual inbox clean makes it possible for you to -start keeping on top of incoming stuff, since it doesn't get buried -between all the old, old stuff. You'll need to process everything in -your inbox frequently (at least once a day), and after you've done -that, you can process a few things from the old pile too. Eventually, -the old pile will be gone. - diff --git a/git-mtime.sh b/git-mtime.sh deleted file mode 100755 index 84c9299..0000000 --- a/git-mtime.sh +++ /dev/null @@ -1,11 +0,0 @@ -#!/bin/bash -# From https://stackoverflow.com/questions/2458042/restore-a-files-modification-time-in-git - -set -euo pipefail - -rev=HEAD -for f in $(git ls-tree -r -t --full-name --name-only "$rev") -do - echo "setting mtime for $f" - touch -d "$(git log --pretty=format:%cI -1 "$rev" -- "$f")" "$f"; -done diff --git a/gtdfh.css b/gtdfh.css new file mode 100644 index 0000000..5253d63 --- /dev/null +++ b/gtdfh.css @@ -0,0 +1,19 @@ +body { + font-face: serif; +} + +a:link { + color: blue; +} + +a:visited { + color: green; +} + +a:hover { + color: pink; +} + +a:active { + color: red; +} diff --git a/ikiwiki.setup b/ikiwiki.setup deleted file mode 100644 index 58c39d3..0000000 --- a/ikiwiki.setup +++ /dev/null @@ -1,37 +0,0 @@ -# IkiWiki::Setup::Yaml - YAML formatted setup file - -wikiname: GTDFH -url: https://gtdfh.liw.fi/ -srcdir: /home/liw/sites/gtdfh.liw.fi/src -destdir: /home/liw/sites/gtdfh.liw.fi/html -html5: true -add_plugins: -- goodstuff -- inline -- attachment -- rename -- tag -- orphans -- brokenlinks -- highlight -- format -- rawhtml -- trail -- sidebar -- pandoc -disable_plugins: -- graphviz -- remove -- smiley -- tidy -- htmltidy -- htmlscrubber -- more -- repolist -timeformat: '%Y-%m-%d %H:%M' -exclude: 'favicon\.ico' -allowed_attachments: mimetype(image/*) -tagbase: tag -rss: true -atom: true -pandoc_filters: "pandoc-filter-diagram" diff --git a/inboxes.mdwn b/inboxes.mdwn deleted file mode 100644 index cc6c5f1..0000000 --- a/inboxes.mdwn +++ /dev/null @@ -1,171 +0,0 @@ -Inputs and inboxes -================== - -Consider how you deal with e-mail. All your e-mail arrives, -automatically, unbidden, unwanted, unloved, in one or more inboxes. -You might have one inbox for work, and another for personal use. -Further, you might have automatic filters that move some incoming -e-mail into other folders: software developers are often on many -discussion mailing lists, each of which goes into its own folder. -Each such folder would be a separate inbox. - -A common anti-pattern for people is to keep e-mail in their inboxes. -They read it, and leave it there. The next time they read e-mail, there -might be some new mail, which they read, and leave there. Eventually, -the mail piles up a lot, and it gets hard to find a specific mail you -may need. Even more importantly, it gets hard to know which mails still -require you to do something. Perhaps there was a mail from your boss -you need to re-read? Or a mail from your mother that you need to reply -to? Or perhaps you replied to her already? Can't remember if you did? - -Treating an e-mail folder both as an inbox and an archive of old mail, -and mixing it further up as a list of things to do, leads to confusion, -angst, and stress. - -Let's make a small change to e-mail handling. Let's keep only -unprocessed e-mail in the inboxes, and do one of the following things -for every e-mail in each inbox, after reading it: - -* delete it, if it is unlikely to be of further use; for example, spam, - or stupid jokes from friends -* reply to it immediately, if you can, and it will only take a minute or two; - for example, your mother asks if you'll be visiting next weekend, and you've - already made plans with your partner to go on holiday, so you can reply - at once saying sorry, not this weekend -* move it to a "needs replying" folder, if the mail requires a reply, but - you don't have time to do that right now -* forward it to someone else, perhaps with a cover letter, if it's their job, - not yours, to deal with it; for example, it might be a question only your - boss can answer -* move it to an archival folder, if you think you might need it later on - -(Compare the above list with "do, defer, delegate, delete, or file" from -the Quickie overview chapter.) - -When you have time, you look into the "needs replying" folder, and reply -to one or more mails in there. After you've replied, you delete or archive -the original mail. - -With this change, you have a better handle on your e-mail. You know that -anything in the inbox is unknown and needs to be processed, and anything -in the "needs replying" folder needs some action, and that anything you -might need later is in the archival folder. No other mails require any -action, and any mails that do require action are easy to find. - -This will make you be much more relaxed about your e-mail. You never need -to worry whether you've replied to everything that needs replying. A further -benefit is that you're likely to reply to mail much faster than before. - -Work versus personal inboxes ----------------------------- - -It can be quite stressful to have to deal with work while you're -supposedly in your free time. Configuring your e-mail so that your -work mails are not visible on your own computer, or not visible -unless you're actually working, is quite a good idea. Keeping the -work and personal inboxes separate is a first step. - -If your work e-mail is not in your face all the time, it's easier -to ignore it, and that makes it easier to relax. - -Other kinds of inputs ------- - -The same processing principles work for all kinds of input, not just -e-mail. You should collect, whenever possible, all inputs in your -life into inboxes, which you regularly process until they're empty. -For each inbox item you decide whether to discard it, do the required -action immediately, do it later, delegate it to someone else, or -whether the item just needs to be filed. - -Hackers tend to mostly deal with digital inputs, but there's always -some physical ones as well. If nothing else, TPS reports and voicemails -about their -cover sheets. If you have more than a couple of inboxes, you may -need to keep a checklist of them. For physical inboxes, it is often -easiest to have as few as possible, but experiment with what works -for you. - -Your phone may also be an inbox. For example, text messages, voicemail, -notes you write on the phone, photos and videos you take, etc., are all -inbox fodder. - -When an input can't easily be put into an inbox, put a proxy there -instead. - -Inbox processing ----------------- - -Some inboxes you should empty frequently, several times a day. Some -can be done more rarely. For example, I usually process my -physical inbox once or twice a week, since any items that go into -it tend not to be urgent. - -When you've processed an item from the inbox, you need to remove it -from the inbox. This means you need to have a place to put it, even -if it is only the trash. We will cover filing systems and other related -tools later. - -Bug trackers: not really inboxes --------------------------------- - -Hackers tend to deal with bug trackers, ticketing systems, and similar -systems. These are not purely inboxes. They're also sort of project -lists, and next actions lists. I have found it most efficient to use -them as places to trawl for inbox material. It's not possible to -remove items from bug trackers just because you've decided what to do -with them. Instead, I review the list of open bugs, and see if there's -anything there that's new or that I need to deal with. If there is, I -add a proxy into my own inbox (or, sometimes, directly as a next action). -I might have a project in my GTD system for a particular bug. - -It's often the case that the total number of open bugs is so large -it's overwhelming. I have found only one way to deal with that: keep -dealing with subsets of the bugs that are most important, and try to -handle bugs at least as fast as they're reported. The rest of the -bugs may have to languish for a while, but if there's more of them -than you have time for, that's unavoidable. - -Inboxes a la Lars ------------------ - -Here are the inboxes I use: - -* physical inbox: letters and other mail, notes written on paper, etc. -* wallet: receipts, other bits and pieces that get collected during the day -* notebooks: notes made while out and about and phone/laptop wasn't available -* backpack: random stuff tends to get collected there -* phone text messages -* phone call log -* phone notebook: I use a note taking application on my smartphone as - a replacement for a notebook, when I can, because my handwriting font - is abysmally hard to read -* e-mail: this is two inboxes (personal vs work); I no longer have a separate - folder for each mailing list, everything goes into the same inbox -* feeds: blogs, news sites, etc. -* home directory for each computer I regularly use: tends to collect - random downloaded files, notes, etc. -* web browser bookmarks: I move any bookmarks I want to keep to - a link page on my website, the actual bookmarks are just a quick - way to save something for later -* all of my bug trackers: I develop software, each project has a bug - tracker, and those need to be reviewed; unfortunately, it is not always - possible to treat the bug tracker as a proper inbox as separate from an - archive -* inbox.mdwn: a plain text file (actually using markdown syntax), - an all-purpose digital inbox for ideas, notes, URLs, phone numbers, etc. -* all my ikiwiki instance's comment moderation queues -* unprocessed photos from camera phone, real cameras -* laundry that is drying or is dry: this sometimes gets delivered on my - desk by my partner, I then need to fold it and put it away; at other times - I realize it's dry fast enough to take it down from the clothesline first - -Information overload --------------------- - -Sometimes processing inputs in this more efficient manner is still not -enough. It may be that you're getting so much input that it's just -not possible to deal with all of it. In that case, you need to filter -away unwanted stuff automatically, or stop it from being sent to you -in the first place. - @@ -1,23 +1,598 @@ -GTD For Hackers -=============== - -* [[!traillink Introduction]] -* [[!traillink quickie-overview text="Quickie overview of the GTD system"]] -* [[!traillink inboxes text="Inputs and inboxes"]] -* [[!traillink projects-next-actions text="Projects and next actions"]] -* [[!traillink doing text="Doing things"]] -* [[!traillink calendars text="Calendars and reminders"]] -* [[!traillink journalling - text="Journalling and other ways of keeping track of things that have - happened"]] -* [[!traillink files text="Keeping track of files"]] -* [[!traillink someday-maybe text="Stuff you maybe want to do someday"]] -* [[!traillink waiting-for text="Waiting for things to happen"]] -* [[!traillink daily-routine text="The daily routine"]] -* [[!traillink review text="The weekly review"]] -* [[!traillink read-and-review text="Read and review folders"]] -* [[!traillink automation text="Automation and checklists"]] -* [[!traillink getting-started text="Getting started"]] -* [[!traillink ungood text="Things that did not work for me"]] -* [[!traillink Conclusion]] -* [[!traillink References]] +[Bullet journal]: https://bulletjournal.com/ +[GTD]: https://en.wikipedia.org/wiki/Getting_Things_Done +[Inbox Zero]: https://en.wikipedia.org/wiki/Merlin_Mann#Writing +[Zettelkasten]: https://en.wikipedia.org/wiki/Zettelkasten +[ikiwiki]: http://ikiwiki.info/ + + +# Introduction + +Getting Things Done, or [GTD][], is a personal productivity system +originally developed by David Allen, and now maintained by the company +he founded. In 2001 Allen published a book, also called "Getting +Things Done", to describe the system, and it was an Internet +sensation, enough to be called a cult. + +This document is a description of my personal implementation of GTD, +based on the books by Allen, and tons of online discussions. If it +helps the reader, great, but I primarily write this so to clarify my +own thinking. + +The GTD system is one of many. Other well known ones include the +[Bullet journal][], [Inbox Zero][] ("GTD, but for email only"), and +[Zettelkasten][] (good for researchers). It doesn't matter what system +you use, or that you any system. The only thing that matters is that +you're happy. For me, GTD helps. + +I started using GTD in the summer of 2006, while I was working as an +independent consultant, and found it hard to keep the commitments I'd +made to others, and do all the things I needed to do to run my +business. I would sometimes wake up in the middle of the night in +panic, wondering if I'd paid this bill or done that thing a customer +had requested. I felt that I was juggling too many eggs, and that the +floor was getting messy. + +After doing some research online, I happened to find out about GTD. I +read more, including the first edition of the book. I hesitated a +little, it seemed like a lot of work, but I took the plunge and +started implementing it for my life. It has been worth it. + +To be honest, applying GTD to your life is indeed quite a bit of work. +Less than I feared, but it does require an effort to get started, and +to keep it up, but it has helped me get my life under control. I +haven't woken up in panic thinking I'd forgotten to do something +important any more. + +Will GTD make your life better? Maybe. It might not. You know yourself +and your life better than I do, and it's your decision to make. You +won't lose much if you try, though. + + +# On productivity + +Productivity is whatever you say it is. GTD is a personal system, +after all. You decide. + +For me, to be productive means that I feel I do all the things I need +to do to to feel happy, satisfied, and fulfilled, and either achieve +my personal and professional goals. That's very wishy-washy, but let +me break it down in concrete statements: + +* I have written down some personal values and goals. I feel I live + according to my values, and either reach my goals, or feel that I + make progress on reaching them. + - I am in a loving, caring, fulfilling, mutually supportive + relationship with my wife. + - I have a list of software projects that I develop and maintain as + a hobby. I implement new features, fix bugs, publish new releases, + etc. + - I do things that improve the world in my opinion. +* Professionally, I make a comfortable living, and my employer or + client is happy with what I do for them. + - I do work that I feel is ethical, worthwhile, and meaningful. + - I meet the goals agreed to with my employer or client. + - I learn new things and become better at what I do, professionally. + - I help others become better, too. + +That's my list. Yours might be different. You might not care about +productivity at work. You might measure everything using money. Your +decision. Whatever you decide is OK. + +To me, being productive is important because it helps me be happy. For +me, work is a big part of my life, and so "being productive at work" +is important to me. Again, you might be different, and that's OK. + +An important measure of being productive, for me, and being in control +of my life and commitments, is how easy it is for me to not do things, +and feel OK about that. Can I drop everything and go for a walk? Can I +go have lunch or dinner or watch a movie with my wife? I can do those +things when I know what I've committed to and what I need in the near +future. If I'm very tired during the day, I take a nap, because it +helps me be more awake later, but I sleep better if I worry less. + +I feel most productive when I can just do the things. In online +discussions, this is sometimes described as "cranking the widget". I +know what I need to do, and I know how to do it, and I merely need to +do it. It might be writing a code module, writing a section in an +outline for a document, or filling the dishwasher. + +I find that one of the things I get from GTD is the idea of separating +the planning from the doing. First I plan: "I need to write this +program, what does it need to do exactly? What's the next concrete +thing I can do to make that happen?" Later, when I'm ready to actually +start doing, I do the concrete thing, whatever it happens to be. By +separating the planning and the doing I can concentrate on one thing +at a time. I don't need to think about, or worry, about all the other +things I could be doing. This helps me concentrate, and if I can +concentrate on only the one thing at hand, I get it done faster, with +less total effort, and with fewer errors. + +If I feel like watching a movie, instead, I know what I need to get +done in the near future, and if there's nothing urgent, I can immerse +myself in the movie. That, too, is easier if I don't need to worry +about other things. + + +# A terse summary of GTD + +This is the shortest summary of GTD I have come up with: + +* Messages, notifications, communications, physical things, + interruptions, etc, that come to you, are either dealt with + immediately, if necessary, or go into one of a defined set of + inboxes. +* When you have time and desire, you process one or all items in one + or all inboxes. When you process an item, you remove it from the + inbox. +* Processing means you decide to do something about the item, discard + it, delegate it to someone else, or defer it until later. + * Do: whatever the item requires you to do, if it's quick, do it at + once. I limit this to things that take at most a couple of + minutes. + * Defer: make a note to do whatever needs doing, somewhere you will + check later. + * Delegate: ask someone or something else to do it. + * Discard: delete the email, recycle the paper, whatever is + appropriate to remove it from your life. +* Occasionally, possibly regularly, review your entire GTD system and + make sure everything is in good shape. This means processing + everything in all inboxes, checking on delegated things, and + checking your notes on deferred tasks. + +Of these, the review is probably the most important part. It's what +keeps the system together. I certainly am not diligent and disciplined +enough to get every detail right every time. Things fall through +cracks, and a review (I do it about weekly) helps me find things, and +also to patch up cracks that things fall into often. + +# GTD in more words + +In this chapter I describe the basics of the GTD system in enough +detail that if you want to implement it for yourself, you can start +doing that. + +The core elements of GTD are: + +* one or more inboxes +* several lists +* a calendar +* a filing system +* a waste basket, trash can, or recycling bin + +I won't go into detail on how to discard things, as I'm certain you +know about that already. From a GTD point of view, the only important +aspect is that you actually remove from your life things that you +don't need or want to store. + +The core lists in GTD are: + +* next actions +* active projects +* what you're waiting for to happen or for someone else to do +* what you may want to do some day, but not now + +You can implement the lists in whatever way you like. I use text files +in git. Actually they're markdown, so that [ikiwiki][] can render a +web site from them, but that's not actually important. You can use pen +and paper, a generic list management application, a GTD application +specifically, a ticketing system, a whiteboard. Whatever works for you +is fine. + +## Inboxes + +An inbox is where incoming things land. An email mailbox where new +mail arrives automatically is a prime example. You can also have a +physical box where you dump snail mail, or anything someone hands you, +or post-its you write to remember to do something. + +Not everything has to go into an inbox. Sometimes things are urgent, +or you have the time and energy to deal with them immediately, and you +can just deal with them as they arrive. If there's a fire in the +kitchen, you deal with that immediately. If someone asks you what time +it is, you answer at once. If you get offered a cup of tea, you either +drink it then, or refuse it. There's no point in a putting a cup of +tea in an inbox to be processed a few days later. + +I process items in an inbox several times a day (email), once a day +(snail mail), or when I do my GTD review (most things). I sometimes +process just one or two items, when that's all I have time for. + +In online discussions, some people are quite strict about inbox +processing. They may say that you have to always process everything in +an inbox, and you must do it every day. I have not found it necessary, +or useful, to be that strict. Whatever works for you is fine. + +I have a bunch of inboxes. + +* a markdown file called `inbox.mdwn` +* a note taking application on my phone +* a couple of email accounts +* several chat systems +* notifications on social media or phone apps +* several ticketing systems +* the desk in my home office (for snail mail) +* the couch in my home office (for clean laundry to fold and put away) + +The exact list is not important here, but I do need to make sure I +remember to check all of them. It's OK to have many inboxes, as +long as you know what they are. + +I treat ticketing systems as inboxes. I check all open tickets from +time to time, to see if there have been any changes, and I treat each +change as being in an inbox. This is, of course, easier for systems +that send me email, but it's workable for any ticketing system. + +Sometimes an open ticket not having changed is something I need to do +something about. That's usually obvious when I review the ticket, and +then I add the thing I need to do to `inbox.mdwn`, to be processed later. Or +I add a reference to the ticket to the inbox, if I need to think about +what to do. I capture the need to do something in my system. + +From a life management point of view, it's important to realize that +an inbox is not permission for others to tell you what to do. If it's +your employer, or your spouse, they may have that power, but in +general, anything that lands in your inbox is best treated as a +suggestion that you consider if something needs to be done. + +Even that can be too much. If you, say, have an open source project +with many users, they each separately feel like they have a right to +ask you do consider something. If that happens rarely, that's fine. If +you get many such requests a day, the cumulative load on you is +excessive. It's OK to filter what gets into your inbox, in whatever +way works for you. Maybe an email filter, or a trusted party. Your +time and your attention are yours, and you should decide how you +spend them. Arrange things so that you are in control. + +## Next actions + +When I've decided that I will do something, but can't do it at once, +because it takes too long, I add it to the list of next actions. Later, +when I'm actually doing things, I pick a item from the list, and do +that. + +For this to work well, I describe the action in sufficient detail that +I remember everything relevant, possibly days later. I find it helps +to write the next action for a future me who has just returned from a +short, but extremely exciting adventure, and needs a little help to +remember the mundane aspects of my life. I don't need to write an +essay, but I do include enough context to trigger my brain to remember +the rest. + +I also find it helps me do things if I write a sentence that starts +with a verb representing a concrete physical action, but also only +describes how to start doing, rather than describing a complete, +polished, perfect end result. Perfection is scary and de-motivating. + +Good examples: + +* Draft an outline for a rewrite of "Getting Things Done for Hackers". + - note "draft" rather than "write": a draft can be incomplete, and + may need further work +* Write a list of at least three ideas of birthday presents for my + wife. + - note how three is a small number, but it's enough to get me + started, and once I'm going, I can go on + - also note how this is about collecting ideas, not choosing a + present + +I find that an action needs to be possible to complete in one sitting. +Thus, "write a novel" is way too big, but "draft a list of five ideas +for names for characters in a novel" is fine. + +It's also necessary for me that a next action is ready to be +done. It can't depend on something else that needs to happen +first. I can't format a new hard drive until I've bought it, and I +can't buy it until I've researched current hard drive reliability +statistics. The first action is to find those statistics. + +I use the following check list to make sure my next actions are well +formed: + + * a _physical_ action ("write", not "think about") + * thinking is part of planning! + * but "draft outline of a plan for..." is an action + * it's clear what I need to do (which widget to crank) + * duration at most 15 minutes, preferably, or at least less than 60, + definitely + * I'm committed to doing it + * does not depend on anything, can be done immediately + * it's clear when it's done + * it's clear which projects the action belongs to, if any + +A list of next actions can be as short or long as you like. I find it +works best for me if it's long enough to have at least one item for +each active project, but short enough that it's easy to pick something +to do. By the time I need to use regexps to search for something, I've +gone overboard. + +In practice, less than one hundred items works for me, but less than +twenty is better. A list longer than about ten is long enough that I tend +to want break it into sub-lists, to make it easier to navigate. In GTD +parlance this means assigning next actions into contexts. The original +David Allen GTD book has contexts such as "at phone" and "at +computer", which make no sense to me. That was a simpler time. + +You can use whatever contexts you like, and you can vary them as +needed. Some of the contexts I use include "working", "hobby time", +"out and about, running errands", "home alone", and "zombie". The +"home alone" context is for doing things to our home network, or home +servers, when my wife's work isn't disturbed by me, say, reinstalling +the home router. The zombie context is for when I don't need to be +particularly awake or alert or able to think clearly, but need to do +things like taking out the trash, doing dishes or laundry, or checking +my spam folder for legitimate mails. + +One extra context I have is "started" for things that take a long +time. As an example, "run the automated test suite 1000 times in a +row" might take all day, but not require my attention except to +occasionally check the test suite is still running. + + +## Projects + +In GTD, a project is anything that requires more than one action to +achieve, but is very likely possible to finish in less than 12 months. +This is a simple, clear definition, and usually meshes well with other +contexts. + +I find it useful to describe a project goal by starting it with "when +this is done" and describing the world after the project has ended. I +have learned, from others and from my own experience, that this aligns +my brain to think about the project end goal, rather than the process +of getting there. + +I further find it useful to describe acceptance criteria for deciding +that the project is finished. This is the difference between "stay at +my mother-in-law's overnight" and "drive north for six hours, then +take a left, and knock on the door". By concentrating on "what", it's +easier to re-think the "how" when something doesn't go as planned. + +Example: + +> _When this is done:_ I have written a novel, and at least three of +> my close friends have read it and not suggested character or plot +> changes. + +When planning what to actually do to advance a project, to choose next +actions, I find it useful to think about the next few steps only. +These are usually fairly obvious, but that depends on the project. A +project to buy a new hard drive is easy; a project to construct a new +Zeppelin is not. The harder a project is, the more things it contains +that you've never done before, the more careful planning of each +action, and the route to the end, needs to be. + +For projects requiring specialist knowledge, consult specialists. + +Also remember that when you set a goal for yourself, you get to adjust +it as you like along the way. Maybe a goal to write a novel turns into +a producing a play. That's allowed. + +## Waiting for + +I add an item to my "waiting for" list when I ask someone else to do +something. I also add to the list when I'm expecting something to happen. +I have two "waiting for" lists: one is a markdown file, the other is +an email folder. When I order something online, to be delivered, I move +the order confirmation email in my "waiting for" folder. This makes it +easy to check that it actually arrives. + +Effectively delegating tasks to others requires keeping track of what, +to whom, and checking that they do them. Even the most competent +people can misunderstand what is requested, or make mistakes, take +longer than intended, fall ill, or suffer from the loss of a loved +one. Checking on progress helps everyone collaborate better: if the +task turns out to be too big, help can be recruited; if someone is +ill, a substitute can be arranged. + +This turns out to be particularly effective when you delegate upward +in a hierarchy, by asking your manager to do something. Managers, too, +appreciate help in remembering their commitments, as long as it's done +politely. + +## Some day, maybe + +I have many things I may want to do, but not right now. So many +things. For example, I might want to learn French some day, or write a +novel, or visit +[Guédelon](https://en.wikipedia.org/wiki/Gu%C3%A9delon_Castle). Some +of these are so desirable to me that I'm unlikely to ever forget, but +for most things, it helps to write them in their own list, the +"someday/maybe" list. + +The "someday/maybe" list can be just a wish list. It can also contain +things others have asked you to do, when you have time. It can contain +things that someone has hinted they'd really like to get as a gift. +Mine also has ideas for programs I might want to write, or features to +add to existing programs. + +This list runs the risk of growing too large. At its largest mine grew +to over 7000 items. (grep is useful.) That's too large to be useful. +("Learn French" was there three times.) I find it helpful to trim it +down if it grows too large. Trimming is helpful not just to make it +easier to find anything, or to get rid of duplicates, but also because +the longer the list is, the heavier a psychological weight it is. +After all, learning every language and visiting every castle in France +is quite a long list, and not likely to ever shorten much. It might be +freeing to have just one language and one castle. + + +## Calendar + +Things that should happen on a particular day, or at a particular time +on that day, go into a calendar. Calendars are a magnificent invention +to help ensure you don't commit to doing two things at the same time. +(Calendar software is a manifestation of an elder evil who sucks your +soul dry.) + +You can use calendar software, or a paper calendar, a handwritten +list, or whatever works for you. + +I used to live a very simple life, with few time based commitments. I +kept everything in my head, except birthdays. This ended when I +started having meetings or other interactions at work. I cannot +recommend ending up in a situation where you have to explain that you +forgot a meeting, or remembered its time wrong. + +## Filing system + +Inevitably, I need to keep, and retrieve, documents for a long time: +receipts, invoices, contracts, pay slips, manuals, etc. Some of these +have an expiry date, but it might be far in the future. Anything tax +related I need to keep for about a decade. A manual I need only as +long as I have the hardware. + +Filing systems are traditionally an area where many geeks who start +using GTD go overboard. Hanging folders? Manila folders? What size? +Filing cabinets? Archival document boxes? Label makers? Alphabetical +or date order, or some classification system? The possibilities are +endless. + +I keep my paper filing system simple. I have a few archival boxes that +I label with the kind of document they contain. I use a label maker, +because my handwriting is illegible. For digital files, I have a +folder `Archive2` where each file is named with an ISO 8601 date, and +some keywords to hint at the contents. (It's `Archive2`, because the +original, `Archive`, turned out to be hard to organize. It had an +intricate sub-folder structure.) + +Once again, whatever works for you is fine. Start simple, and when your +GTD system is working otherwise, if you feel like it, spend the +necessary effort to implement the perfect filing system. Make Miss +Lemon proud. + +## Pending and support + +It's awkward and tiresome to fetch documents from the main filing +system, and return them, for things you need often because they're +relevant to your active projects. I have a separate stash for such +documents, which I call "pending and support". I have an email folder +with that name, and I use my work desk surface for physical documents, +and my home directory for digital files. It's messy, but it works for +me. + +## The review + +For me, clearly the most important, the most energizing, the most +meta-productive part of using GTD is the review. I try do one every +week, but that varies. If I skip the review for a month I get angst, +and have difficulty concentrating. My brain loses all confidence that +I can support it by keeping track of things externally and tries to +remember everything without help. + +The purpose of the review is to make sure I haven't forgotten to +process any inbox items, that I've made progress on all projects, and +that I have a clear set of things I can do in the near future. In +short, that everything is in order, and nothing is neglected. The +review is also a time of contemplation, thinking, planning, and +envisioning a bright future. + +Doing a review tends to calm my subconscious, and make me feel +energetic. If I do my review in the morning, I am often in my most +productive mode the rest of that day. This is why I avoid doing it on, +say, a Friday evening, as the temporary energy boost would be lost while I +sleep. + +My review sometimes take hours, but I tend to take breaks to have tea +on the balcony with my wife, and other important things. If I'm +feeling it is urgent, I can usually do a reasonably thorough review in a +couple of hours if it's not been more than a couple of weeks since the +previous one. + +My checklist for conducting a GTD review is ("iteration" is the +interval between reviews): + + * Write a journal entry summarising the past iteration. + * Review, and dump any thoughts into an inbox: + - journal entries for the past iteration + - calendar for the past iteration + - calendar for the next month + - waiting-for: + - in GTD files + - personal email + - work email + - pending-and-support: + - personal email + - work email + - review someday/maybe + - empty head of things: any pressing thoughts or worries that + haven't yet been captured into the GTD system + * Process all inboxes: do, delete, delegate, defer, discard. + * Review projects. Make sure each has at least one next action. + * Review next actions list. Are they all of good quality? + * Re-process all inboxes: do, delete, delegate, defer, discard. + - new things keep arriving + +This isn't the perfect review process, but it works well enough for +me. + + +# Higher level GTD + +The full GTD system described by David Allen covers life management at +higher levels than the mundane "do these things to achieve these +goals". I'm not describing the higher levels in detail, but in short: + +* what's your purpose in life? what are your principles? + - why do you exist? + - who are you? +* what is your vision for the medium to long term future? + - what does success look like for you, in the long term? +* what areas of your life are you particularly focused on? + - what parts of your life do you need to maintain, or improve, or + pay attention to? +* what are you goals for the next year or two? + - these generate projects, which are shorter + +These make sense to review annually. However, you should probably not +worry about these until your everyday is under control. + +The second edition of Allen's GTD book describes these better than the +first one. + +# Advice + +Here I give some advice about implementing a GTD system. + +* Don't use software, or write your own software, as part of your GTD + implementation, until after you've been doing it manually for a + while, and have a deep understanding how you want your system to + work. + - I did not write two outline applications, or a ticketing system, + or a thing to nag me about things. You can't prove I did. + - software is usually inflexible, and a GTD system will have corner + cases, edge cases, and special cases that require flexibility + - start with pen and paper + - after various other software approaches I have ended up with + markdown files in git, edited with Emacs; this seems to be + convenient and low-tech for me + - git helps me keep my GTD system in sync between work and personal + laptops, and helps guard against catastrophic editing mistakes +* It can, however, be helpful to automate aspects of your life or GTD + system. Having recurring calendar entries is helpful. Having a + monitoring system to remind you about inboxes you've not touched may + be overkill. +* Use checklists for things you need to remember, or do repeatedly, or + that you may need to do in a hurry under great stress. +* Consider building a [personal knowledge + base](https://en.wikipedia.org/wiki/Personal_knowledge_base), or at + least keep a journal. +* You can start big, or small. You can start applying GTD to only part + of you life, and expand that as you get comfortable with the system. + Or you can pile all your incomplete stuff onto a desk and let GTD + take over your life. + + +Finally, productivity hacking your life, and improving your GTD +system, is a fun hobby. It does not seem to be a way to be +significantly more productive, and it can prevent you from having tea +on the balcony. I recommend only hacking your life for increased +productivity when it improves your life. + +Below is an image of my first inbox, when I first started implementing +a GTD system for myself. + +\ + +# Acknowledgments {.unnumbered} + +Thank you to Greg Grossmeier and Heiko Schäfer for feedback on this document. diff --git a/introduction.mdwn b/introduction.mdwn deleted file mode 100644 index 157c686..0000000 --- a/introduction.mdwn +++ /dev/null @@ -1,108 +0,0 @@ -Introduction -============ - -David Allen's "Getting Things Done", or GTD for short, -is a popular, powerful system for -managing one's life. If you have trouble dealing with your e-mail inbox, -or feel you're drowning under a flood of inputs and information, or -just don't seem to have time to do everything you think you should be -doing, or others want you to do, then GTD may be a good thing for you -to consider. - -This book explains how I, a computer geek, have -implemented it in my own life. It is aimed at -everyone whose lives include a lot of computer use, and who know how -to use their computers. - -This book stands independent from Allen's three books on GTD, but -you'll benefit from reading the first or third of those as -well. (The second one should be considered optional.) I provide -a different view of, and perhaps opinion of, the GTD system. - -I discuss what has been good about GTD for me, what has been hard -to implement, and what has not worked. My goal is to explain what -I do, and provide inspiration to you for building your own -GTD system. - -GTD is not a system you buy in a shop and install on your desk. It is -a meta-system: it provides some tools, a lot of guidelines, and -principles, from which you create a system that works for you. For -example, GTD assumes you will maintain lists, but does not specify -how to do that. You can maintain a list on a pad of paper, in a text -document on your computer, or by sticking photos of people on a -notice board. It all depends on what kinds of things you need to -keep track of, and on what tools you have and enjoy using. I am -not going to discuss specific software tools in detail, since I have -not made a survey of them. I will explain what I use myself. - -Why GTD? Why any system? ------------------------- - -In the middle of 2006 I noticed that I was massively failing to -do things I'd promised to do, or that I wanted to do, or that I -absolutely had to do. I was forgetting to buy food before a holiday, -and then scrambling to feed myself while the shops were closed. -I had been an independent consultant/contractor for a year and -a half, and struggling to meet deadlines. I kept doing things, -then realising some other things were about to explode in my -face, and switching to do deal with that, until I noticed another -emergency brewing. - -I realized that I was under too much stress, and this -made me unhappy, and that made me less productive, which made -me more stressed, and that there was no end to this recursion. -I needed to deal with it, and decided to spend a bit of time to -do so. - -I looked at a few personal productivity systems, but they didn't -seem very convincing to me. I tried cooking up my own, but felt -my own attempts didn't really solve the problem. I switched from -keeping everything in my head to writing everything on post-its, -but then I kept losing the bits of paper, or forgetting to read -them at the right time. - -I happened to remember someone blogging about the GTD system, -and when I read about it, it clicked. Pieces fell into place -and things started to make sense. I started applying GTD to -my life, and my life started getting better. - -I don't know if it was purely because of GTD, or mainly because -of GTD, but having GTD shape my thinking about these things -definitely made a difference to me. - -It might be that any of the other myriad personal productivity -systems will do equally well. I haven't tried many of them, -so I don't know. I'm not trying to convince you one way or -another: I explain what I do, and why, and you decide if -it makes any sense to you. - -A brief history of GTD and its place in the greater sociohistorical context of humanity ------------------------ - -Personal productivity systems have been around for a long time. -Allen published his first GTD book in 2002, and for the next -few years, there was quite a lot of buzz about it on the Internet. -Something about GTD spoke to geeks, and they blogged about it, -and dived into endless discussions about which color pen to use -to write things down, or which software to use to keep an outline -on what color computer. By 2007 the buzz had mostly died, and -those who liked GTD kept using it. - -An influential blogger during that era was [Merlin -Mann](http://www.merlinmann.com/), and his most important creation was -"Inbox Zero". It's an elegant condensation of the GTD system for -dealing with e-mail, and that may be all you need. Many of us hackers -pretty much do everything via e-mail, so if you get that under -control, you'll be fine. Go read. - -Technicalities --------------- - -This book is written using an [Ikiwiki](https://ikiwiki.info/) -instance, used as a static site generator, - -The book is licensed under a CC-BY-SA 3.0 (Unported) license. However, -the site is only editable by myself. - -"Getting Things Done" and "GTD" are registered trademarks of the -David Allen Company. diff --git a/journalling.mdwn b/journalling.mdwn deleted file mode 100644 index 56d02c8..0000000 --- a/journalling.mdwn +++ /dev/null @@ -1,51 +0,0 @@ -Journalling and other ways of keeping track of things that have happened -======================================================================== - -A calendar tells you what should happen in the future. -A journal or diary tells you what you did in the past. -You can combine them, and treat past calendar items as a sort of journal, -but a calendar tends not to be a good format for writing down what you -did or thought in any detail. - -The main benefit of a journal is to have a place to record your thoughts, -and those actions that you may need to remember in the future. -The level of detail you use depends on your circumstances, time, and energy. -For example, if you do scientific research, you'll have a lab journal or -similar book in which you write down all your experiments and conclusions -and thoughts related to them. - -I use a set of text files (markdown files) for capturing the thought -processes when developing software (they're actually part of a private -Ikiwiki instance). -I think out loud by writing down my thinking process, -and try to do this with the minimum of self-censorship. -The journal is not meant for others to read, -and this gives me a lot of freedom to be as stupid and wrong and silly and -opinionated (and occasionally rude) as possible. - -Journalling can require a bit of effort, -but it can be very helpful. -The process of expressing thought processes in writing makes them more -explicit, and often more clear. -Anything that's hard to express tends to be unclear in the head, too. -Later, a journal can be helpful to answer things like -"what was I thinking?". - -Apart from effort, journalling requires time. I type reasonably fast, -so the extra time to write down my thoughts in some detail, as prose -that's easily readable later, is not a big overhead. Others might prefer -to keep a handwritten journal, and only jot down the more important bits, -and stick to keywords. Or record audio, perhaps. Experiment with what works -for you; maybe you'll find something, or maybe you'll find it's all wasteful. - -The act of journalling should be as easy as possible. -There should be minimal steps required to start writing, -and the only requirement for the actual text should be that it's expressing -what you're thinking as you write it. -A plain text file works wonderfully; a simple word processing document -would work too, if you prefer that kind of writing tool. - -Apart from journalling, you may want to have some automatic logging -of events in your life. Anything that you want to keep track of, if -it can be logged automatically, is easy. Anything that requires manual -effort is likely to not work quite so well. diff --git a/list-chapters b/list-chapters deleted file mode 100755 index 55daa28..0000000 --- a/list-chapters +++ /dev/null @@ -1,6 +0,0 @@ -#!/usr/bin/awk -f - -$2 == "[[!traillink" { - sub(/\]\].*/, " ") - print tolower($3) ".mdwn" -} diff --git a/local.css b/local.css deleted file mode 100644 index 0356191..0000000 --- a/local.css +++ /dev/null @@ -1,5 +0,0 @@ -div#pagebody { - max-width: 40em; -} - -.recentchanges .diff { display: block; } diff --git a/markdown-to-pdf b/markdown-to-pdf deleted file mode 100755 index 732a456..0000000 --- a/markdown-to-pdf +++ /dev/null @@ -1,44 +0,0 @@ -#!/bin/sh - -set -e - -book_prelude() -{ - cat <<eof -<html> -<head> -<title>Book</title> -<link rel="stylesheet" href="book.css" type="text/css" /> -</head> -<body> -eof -} - -book_end() -{ - cat <<eof -</body> -</html> -eof -} - -chapter() -{ - cat <<eof -<div class="chapter"> -eof - - markdown "$1" - - cat <<eof -</div> -eof -} - -(book_prelude -for f in "$@" -do - chapter "$f" -done -book_end) > book.html -wkhtmltopdf book.html book.pdf diff --git a/person.mdwn b/person.mdwn deleted file mode 100644 index d3b7dfa..0000000 --- a/person.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -[[!meta title="pages tagged person"]] - -[[!inline pages="tagged(person)" actions="no" archive="yes" -feedshow=10]] diff --git a/projects-next-actions.mdwn b/projects-next-actions.mdwn deleted file mode 100644 index 39cd6e3..0000000 --- a/projects-next-actions.mdwn +++ /dev/null @@ -1,180 +0,0 @@ -Projects and next actions -========================= - -In the GTD system, a "next action" is a physical action you can take, -preferably something that lasts a fairly short time. Examples of -next actions would be "write e-mail to project mailing list explaining -your plan to implement a new test driven development approach", or -"buy apples and bananas for home". - -A **bad** next action would be "start a side business". It's bad for -two very important reasons: - -* it's not short; indeed, it might be of indefinite length -* it's unclear when it's finished - -When you actually start doing things, it's much easier if you know what -you need to do, and when you're finished. A **good next action** would -fulfill the following criteria: - -* a _physical_ action ("write", not "think about") - * thinking is part of planning! and that should happen during a review phase - * planning can be broken down into next actions, however -* it's clear what I need to do (a widget to crank) -* duration at most 15 minutes, preferably -* I'm committed to doing it -* does not depend on anything, can be done immediately -* it's clear when it's done - -Obviously, some things you want to get done are going to take a lot of -time. That's OK: they just should not be next actions. Next actions need -to be things that you just do. No more thinking or planning should be -required. - -Anything that takes more than one step (more than one next action), -is called a project in GTD. Like next actions, projects should have -a clearly defined goal so that you know when you're finished. For -example, "form a corporation for side business" might be a good -project: - -* it's clearly defined (it's done when the corporation is formally and - legally founded, and has a bank account, accountant, e-mail address, - and other such things) -* it takes several steps: decide on name, register, open bank account, etc. - -Also like next actions, projects should be finished within a limited -time, though the time will be much longer. Next actions should typically -be doable within half a day (but shorter is better), whereas projects -might last up to a year. - -It's a good idea to write down the goal of a project in a sentence or -a paragraph. This concentrates your thinking to be directed at achieving -that goal and makes it easier to avoid spending time on things that are -related to the goal, but don't help you achieve it. - -Update: Finishing things is an important motivator, at least for me. -It's probably a good idea to prioritise finishing existing projects, -and to scope and plan projects so they're easy and quick to finish, to -gain from the motivational boost. - -Update: Getting started in the morning can be difficult. Sometimes it -helps to have really simple, tiny next actions to choose from that you -can do and get started. I tag such actions with a "zombie" label, to -find them easily. - -Keeping track of projects and next actions: the art of lists ------------------------------------------------------------- - -You'll likely have more than a handful of projects or next actions. -Even if you only have a few of each, it's best to write them down. -The human brain is not good at remembering things without triggers, -whereas even the cheapest pen and piece of paper will do lists with -excellence. (In fact, my memory seems to work better the more I write -things down.) - -You should keep one list of projects, and another list of next actions. -You can keep them in any way or form that you like: - -* a single plain text file for each -* a web page for next actions (so you can read it on your phone), and a - folder on your computer's desktop for every project -* using an outliner: one tree for next actions, one for projects -* using a specialized GTD application -* a sheet of paper for next actions, and a project folder for each project - -If you choose to have one folder per project, whether digital or physical, -that provides a convenient place to store files related to that project. -However, this requires all files to be arranged according to project, -which can be inconvenient: if you have two projects related to the same -software, do you check out the source code twice, once per project folder? -You might instead keep a simple list of projects, and then store the -supporting files in a way that is more natural than per project. Or you -might decide that per-project is the natural way. Your choice. - -There is one right way to do this: anything that you do that helps you -keep track of things is fine. Anything that is a hassle or gets in your -way is wrong. - -Next action contexts and categories ------------------------------------ - -The list of next actions is what you will be dealing with most with GTD. -It is important that it's easy and fast to use. However, as soon as it -grows longer than two or three dozen entries, it will become hard to -pick something from it quickly: you need to read through a lot of it -to find something suitable to do. - -Say you're waiting for the bus, and you have maybe ten or fifteen minutes. -You have your laptop, and there's a place for you to sit. This would be -a perfect time to knock off an item from your next actions list, but -what should you do? If it takes five minutes to scan the list and find -something to do, you've wasted maybe half of your available time. Not good. - -You should break down the list by context or other suitable category. -A context is the things that are required for you to do the action: -"at phone" would be the context for anything that requires you to use -your phone; "online" would be all the things you need Internet access -to do; "at home" for things you must be at home to do, etc. - -Productivity geeks have spent inordinate amounts of times figuring out -the ideal contexts and categories -for them. This is an easy thing to obsess over. However, it's -also clear that nobody else can decide what contexts suit you than yourself. -Still, for inspiration, here's the list of contexts I use: - -* **In progress**: for anything that has been started, but is currently - waiting for something, typically a long computation being performed by - a computer -* **Unfun**: anything that is unpleasant, and is therefore easily postponed; - having this as its own category helps avoiding that (also, I have a rule - that every workday at least one unfun thing needs to be done) -* **At phone, able to call**: for phone calls one needs to make (a special - category of unfun, for me) -* **Errands**: things that require you to go somewhere, such as a shop, or - office, or meet someone outside your normal locations -* **With person X**: things that need to be discussed with a specific - person, either in person or perhaps over the phone -* **At home, not using a computer**: cleaning, dishes, etc. -* **At home, using computer**: typically involves a desktop computer, or - external hard disks, or a printer/scanner, or other hardware that is - hard to carry -* **At laptop, offline**: the laptop being my primary computer, this is all - the things I need to do at a computer, which don't require Internet access; - I travel a bit, and I often go sit in a cafe to work a bit, and so I can't - take the Internet for granted; there's a lot of things that fall into this - context, so this is often quite a long list -* **At laptop, online**: like the previous one, but these require both the - laptop and Internet access - - -"My lists are too long" ------------------------ - -Inevitably, life dumps more on you than you can handle, at least in -the short term. I feel like that every Monday morning. One sign of -this is that my next actions list keeps growing, and doesn't ever -seem to get shorter. - -Sometimes this becomes so overwhelming I can't stand it, and I need to -do something about it. My main strategy is to drop commitments until -I have the situation under control again. For example, if I've got -five ideas for blog posts to write, I'll delete those, or move them -to someday/maybe. Or I find other things I can wriggle out of doing, -though sometimes that requires careful diplomacy (also known as -throwing a tantrum). - -The feeling of being overwhelmed is an important indicator to me -that my level of stress is rising too high. In principle, it doesn't -matter if your next actions list is very long, as long as you keep -doing each thing before it's too late. However, if I'm under too -much stress, the mere length of the list starts causing stress, and -I start avoiding even looking at it, and then everything starts -falling apart. - -And that's why I try to keep my lists at manageable lengths. - -Before dropping commitments, I try to do things like doing as many -quick tasks as possible, or avoiding new commitments while I deal with -the old ones. Those strategies tend to work only if I'm not already -overstressed. - diff --git a/quickie-overview.mdwn b/quickie-overview.mdwn deleted file mode 100644 index c1ea565..0000000 --- a/quickie-overview.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -Quickie overview of the GTD system -================================== - -GTD is a system for managing your life: what you want to achieve, -how you plan to achieve that, and how you deal with all the stuff life -throws at you. You decide goals, the system helps you reach them. - -A condensed summary of GTD: - -* stuff enters your life, and you either deal with it immediately, or put it - in one or more inboxes -* you empty your inboxes regularly from stuff -* stuff is dealt with by one of the following: - - **do it at once** (if it's quick, or you have to, or really want to); - - **defer** it for later; - - **delegate** it to someone else; - - **file** it somewhere (if you may need it later); - - **discard** it (ignore it, throw it in a trash bin, whatever) -* keep several lists: - - **next actions**: deferred stuff; - - **projects**: anything that needs more than one next action to be - finished; - - **waiting for**: delegated stuff; - - **someday/maybe**: what you may want to do someday, but isn't an active - concern right now -* at least once a week, process all inboxes, and review all lists -* have an archiving system for documents and such -* have a system for keeping handy files and other things relevant - to current projects and next actions - -You may now skip the rest of the book. - diff --git a/read-and-review.mdwn b/read-and-review.mdwn deleted file mode 100644 index d950c84..0000000 --- a/read-and-review.mdwn +++ /dev/null @@ -1,60 +0,0 @@ -Read and review folders -======================= - -I'm bombarded with things to read or watch. Friends and co-workers give -tips on interesting, funny, or useful things to read. Bosses point me -at other things to read. I'm further subscribed to a bunch of -RSS/Atom feeds, and I follow a few news sites, which often have stuff -I want to read. And so on. There's no end of things I could read. -The army of monkeys trying to randomly re-create Shakespeare are filling -the Internet with other stuff instead. - -I cannot possibly read everything at once. I need a way to deal with -things I want or need to read, so that when I have time to read, I can -go through stuff that is waiting to be read. - -It's important, at this point, to point out, pointedly, that there is -often no need to read everything. The most important way of dealing with -information overload is to be selective of what you spend brain cycles -on. However, however selective you are, there's always things to read. - -The **read and review** pile, or folder, or list, is an important tool. -When you find, or are given, something to read, or watch, or listen to, -or otherwise process, and you put it on the pile. In old times, -our ancestors would print it on paper and put the paper on a pile. -These days, purely digital things are practical. - -* **Web pages** can be bookmarked. You can keep a "read and review" - bookmark folder. When you've read the page, remove the bookmark. -* You can also save web pages on your local hard disk. This is useful - for reading offline, and also for archiving the page in your filing - system. The Firefox Save Page WE extension is excellent for this - (see <https://addons.mozilla.org/en-US/firefox/addon/save-page-we/>). -* You can have a "read and review" folder for e-mail as well. Newsletters, - and any other e-mail that's long and takes a while to read, can be - put there. -* I read e-books either on my Kindle device, or on my laptop, depending - on the format. Unread e-books are on the home screen on my Kindle - (or if the list grows very long, in a folder for unread books). PDFs - and other big-page formats are in my laptop's "read and review" folder. -* I keep paper books, magazines, etc., in random piles around my home and - at the office. They're rare enough and few enough that I don't need - a dedicated place to keep track of them. Likewise for DVDs to watch. - -For web pages: I used to do the bookmark thing, but it turned out to be -annoying, so I now use MAFF heavily. - -I usually try to read things in a FIFO order. I've found that a document -that's boring or unpleasant or otherwise easy to push later, always gets -pushed later. Since there's always new material coming in, there's -never a time when the boring document is the only one to be read. Sticking -to FIFO, unless there's an urgent reason to avoid it, is a good way -of avoiding a pile of documents that never get read. - -My threshold for putting something into "read and review" is low. -That means a lot of things go in there that I don't really need to -read. That is actually OK: at the time when I encounter a link on -IRC, for example, I may not have time to even evaluate the document -enough to decide whether it is worth my while to read it. So I just -stuff it into "r&r" and evaluate it when I have time for it. - diff --git a/references.mdwn b/references.mdwn deleted file mode 100644 index da1b001..0000000 --- a/references.mdwn +++ /dev/null @@ -1,7 +0,0 @@ -References -========== - -* Getting things done - - <https://www.librarything.com/work/1844807> -* The NOW habit : a strategic program for overcoming procrastination and enjoying guilt-free play - - <https://www.librarything.com/work/7934/details/46964220> diff --git a/review.mdwn b/review.mdwn deleted file mode 100644 index 60a2160..0000000 --- a/review.mdwn +++ /dev/null @@ -1,80 +0,0 @@ -The weekly review -================= - -So you've got your lists set up, and you process your inboxes daily, -and tasks flow smoothly through the projects and next actions lists. -How do you know everything is OK? You need to take a look at every -part of your GTD system, and your life, to make sure everything's in -its right place, and you've not forgotten anything. - -The weekly review is a fundamentally important part of making sure -you stay on top of things. You need to review all your lists, and -calendars, inboxes, etc., and have a short meditative moment where -you reflect your life, and try to think of anything you may have -missed so far. If you do this regularly, and with some thoroughness, -you'll be certain that you've captured everything into your system. - -You might not need to do such a review weekly. If you live a very -calm, regular life, you might only do it rarely. On the other hand, -if your life is a maelstrom, you might want to do a review more often -than once a week. Experiment, and see what works for you. - -Here's my checklist for doing a weekly review: - -* Process inboxes. -* Review journal entries since previous review. Write a summary of the - highlights of what has happened. -* Review calendar entries since previous review, and for the next month. -* Empty head from things. -* Review projects. Make sure each has at least one next action. Remove - any projects that are finished or aborted, or move them to someday/maybe - if that's appropriate. -* Review next actions list. Are they all of good quality? -* Review waiting for list and mail folder. -* Review pending and support files: - * physical folder at home - * folder in e-mail -* Review someday/maybe. -* Review "Read and Review". -* Review areas of focus, goals. -* Re-process inbox. - -It usually takes me a couple of hours per week to do a good review of -the entire system. Sometimes more, if I do a thorough review of all -my open bug reports, for example, but I only do that if I have the -time, and haven't done it in a while. (A thorough review of the bug -reports tends to mean reading through everything, and sometimes checking -that bugs still exist.) - -It's common for me to postpone doing a review, if I'm tired or busy -or have any of a number of other excuses. If it gets really bad, -I postpone the -review for months. In that case, it can take a bit of an effort to do -the review, which acts as further encouragement to push it forward. - -The way I get out of that is that I need to be reminded of the strong -feeling of relief and being in control that I get after doing a review -properly. -I feel that I'm on top of things, that regardless of what surprises -the universe may throw at me next, I know where I am now and what I need -to do next. (And then I often go read the Internet instead, but that's -another problem.) - -In fact, doing a review gives quite an energy spike for me. I feel -motivated to work on things right after a review. Because of this, I -try to schedule my reviews for Monday mornings rather than, say, -Friday evenings. - - -Other reviews -------------- - -In addition to the weekly review, it is good to have another kind of review -about once or twice a year. For this, I find it's best to do a weekly -review first, and then concentrate on bigger issues: what do I want -out of life? How do I want to live in one year, five years, twenty years, -or in my retirement? What do I need to do to achieve those things? - -I've not done much of that yet, so I don't have a lot of concrete advice -about that. I'll add more about it when I do. - diff --git a/sidebar.mdwn b/sidebar.mdwn deleted file mode 100644 index f670a10..0000000 --- a/sidebar.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -See also: - -* [OpenLibrary](https://openlibrary.org/works/OL16701871W/Getting_Things_Done_for_Hackers) - -<hr /> - -This site is written by [Lars Wirzenius](https://liw.fi/). - -This site is not publically editable, but I welcome comments and -feedback, via e-mail. - -<hr /> - -All content on this site is copyrighted by Lars Wirzenius. diff --git a/someday-maybe.mdwn b/someday-maybe.mdwn deleted file mode 100644 index 3f8c3f5..0000000 --- a/someday-maybe.mdwn +++ /dev/null @@ -1,20 +0,0 @@ -Stuff you maybe want to do someday -================================== - -You probably have things you will want to do someday. For me, one of -these things is to learn French. Some people keep a "bucket list". -Perhaps there are places you'd like to visit, or people you'd like -to see perform, or books you'd like to read. - -It's good to keep track of these things: otherwise the brain tends to -keep coming back to them, so they don't get forgotten, and that tends -to waste time and energy. Keeping a list lets the brain relax. - -The "someday/maybe" list is for things you **may** want to do -**someday**, but that aren't something you want to do right now. -You might do them quite far in the future, and you might even -decide later that you don't want to do them after all. Or you might -keep them on your list forever, just because keeping them there makes -you feel better about yourself. - -Cherish your someday/maybe list. It's made of dreams. diff --git a/ungood.mdwn b/ungood.mdwn deleted file mode 100644 index 9d136e2..0000000 --- a/ungood.mdwn +++ /dev/null @@ -1,63 +0,0 @@ -Things that did not work for me -=============================== - -Here's a random pile of things that I've experimented with but that -did not work for me. - - -Split systems: personal versus work GTD ---------------------------------------- - -I've tried having a separate GTD system for work and personal lives, -but as a free software developer, the two are mixed enough that it's -annoying to keep the two systems in sync. For example, if I find a -bug in Debian, while doing work, should reporting it and maybe fixing -it be a work-GTD thing or a personal-GTD thing? It's really both: -the bug affects my work, and I am a Debian developer in my free -time, so it should be in both systems. - -Another problem is that I often need to do personal things in the -middle of the workday. I might need to get a haircut during a lunch -break, for example. If it's only in my GTD system at home, I don't -remember the haircut. I can set up a reminder system, but that's -then part of my GTD system. A single system is simpler, for me. - -Having a single system is not without problems, of course. The -biggest obstacle I have is doing the weekly review: does it count -as work time or not? I've experimented with various approaches, but -haven't got a good solution. Maybe I should do every other review -during work time, and every other in my own time. - - -Fancy software solutions ------------------------- - -I've tried several software solutions for keeping GTD lists. Some -of them were developed specifically for GTD, others were more generic. -I've even written a couple of tools for my own GTD use, to support my -own implementation of the GTD system. - -All of these software solutions have turned out to have the same two big -drawback for me: I spend too much time fiddling with the tool (instead of -doing useful things), and sooner or later the software gets in my way. - -The most useful tools I've found are outliners, but I don't use even -those anymore. I now use a set of plain text documents, which I edit -with gedit (the GNOME text editor). There's no outlining, formatting, -highlighting, sorting, organizing, or any other kind of tool support. -It's just words on lines of text. It's wonderful. - -This is what works for me. I'm a simple kind of guy. You may want to -try various programs yourself and if you do, you may find that you -like them better than plain text. That is good. - - -Non-digital solutions ---------------------- - -I initially implemented GTD on paper, and that was good for getting -started, since it avoided getting hung on tool choices and setup. -However, I don't seem to work well with keeping lists on paper, -or journalling on paper, or doing anything that involves using -a lot of paper. For me, a digital solution is pretty much required. - diff --git a/waiting-for.mdwn b/waiting-for.mdwn deleted file mode 100644 index 2c76a84..0000000 --- a/waiting-for.mdwn +++ /dev/null @@ -1,55 +0,0 @@ -Waiting for things to happen -============================ - -After delegating something, you usually want to keep track of the issue -to make sure it gets done. Minions are often lazy, and -you don't want to be the kind of overlord who forgets having given orders. -So you need another list: a list of things you're waiting for to happen. - -This list is not just for delegations. It's also for other events you're -waiting for. For example: - -* you've ordered something online, and are waiting for it to arrive -* you've started a week-long benchmark run, and are waiting for it to finish -* you're short of cash right now, so you're waiting for your bonus, and - after it arrives, there's a bunch of things you'll need to do, or you'd - like to do - -I use a "waiting for" list of the following format: - - * Bonus arrives. - 2009-09-01 - - buy disco ball - - pay credit card - -This format makes it easy to keep track of what you're waiting for, -how long you've waited already, and what to do after the event happens. - -You could keep track of the reactions to an event elsewhere. For example, -they might be in the project list, and the project would be marked -"blocked" in some manner. However, there's no direct link from the -"waiting for" list to the project list, and you'd need to remember -that there are blocked actions, so you'd at least need to write down -pointers to the blocked projects. - -I also keep another kind of "waiting for" list, for things that will -need to be finished the same day. I call this the "in progress" list, -and it's actually a context in my next actions list. -It usually contains things that automation is doing for me, but that I need -to remember to check up on when they're finished. For example: - -* a half-hour test run for some software I'm writing (it's so easy to - start one, then lose the window under a dozen others, and only notice - it a week later: this seriously slows down development speed) -* Roomba is vacuuming in another room -* the washing machine is running; when it's done, it needs to be emptied - and possibly another load started -* a co-worker is looking up some information and promised to have something - by lunchtime - -The "in progress" list is otherwise like the "waiting for" one, but I -keep it at the top of the "next actions" list, so it's always in my -face. This makes it harder to forget stuff that is currently happening. -The crucial difference, for me, is that "in progress" needs to be -finished the same day, whereas "waiting for" may usually wait until the -next weekly review. |
