For the Wynn

I write about o11y, tech, philosophy, and more.

My BASB Implementation in Org Mode v2023-06

This post is part of the Building My BASB in Emacs - 2023 Capstone Report series.

Table of Contents
Categories: [Personal Knowledge Management]

The meat and potatoes of the series! The stuff you’ve probably been waiting for!

Rather than dump the entirety of my init folder on you, I’ve opted to give a more narrative explanation of how the system came to be. If you are unclear about anything, please reach out on the socials and I’ll do my best to clarify.

Reminder: I use the term BASB to refer to the solution we’re building in Org.

I’m sure I’ll update this page more than a few times, but expect I’ll write a new version after enough time passes.

Global Configurations

There aren’t that many global configurations I want to call out at the top. Generally, I write my init file in org, add packages and comments that I want to try, and add in commands I want to keep handy to my general.el keymap.

That said, there is one thing I want to encourage anyone considering org to take a look at: you should reverse the insert order of headings so that new entries come in at the top… a “reverse cron” approach to insertion if you will… rather than the default of appending to the bottom.

(setq org-reverse-note-order t)

I’ve found that this approach leverages the fact that we tend to want more recent things more at hand than older things. Plus if you stick wth the system for a while, appending to the bottom often entails a lot of scrolling.

Your mileage may vary, but worth noting.

BASB: Beginning with the End in Mind

I find that the nature of BASB creation inclines people to focus on the BASB as the target output. But that’s of course, not the real goal. The real goal is to figure out what other stuff this new tool/practice enables. Keeping that in mind, I find I can’t talk about the thing without talking about what I use it for and want from it first.

As such, I will walk my setup through each of the target use cases I aim to solve. I’m sure it will evolve as I add more, but the needs here are what drive the system, not the system driving my needs.

My Target Use Cases

Journaling and Regular Reviews

This is the number one use case because creating a regular habit that uses the tool multiple times per day is key to really learning it. Journaling isn’t a technically complicated use case, just requiring some templates and a place to journal in the system that doesn’t require thinking about where the entry goes.

I took a cursory glance through various options inside of org, and opted for using org-roam’s dailies to handle this. I’ve used diary mode in the past, but I liked org-roam’s capture system that was tied to it, so I went that direction. I also use org-roam for other things which I’ll describe later, so that was a reasonable fit.

This does mean that I break my principal of a single org file almost immediately, since org-roam does separate daily files by default. However, experience has taught me that I never mess with these physical files themselves, so I think it’s fine. Putting journals in one file is also a surefire way of eventually causing a performance problem somewhere down the line. Might as well head that one off before we get there.

Additionally, I keep all my templates as org files in a sub-directory, ~/org-roam-repo/templates. I find using full org files much easier to visualize and edit rather than storing them as strings in my init file. I mean, I can only handle so many \n’s before my eyes cross… and I’m a person who likes regular expressions.

This also shows the first example of my principle for subdirectory use in org:

Prefer a flat, single directory where possible. Use sub-directories for programmatic separation of content as needed.

In this case, having a single template directory (no files of which are included in the org-roam index) makes them easier to find, refer to, and keep out of the way of other files in BASB.

The following templates apply to this use case:

Daily notes themselves go in a special subdirectory, ~/org-roam-repo/journals. The same reason as above applies, in that org-roam expects a directory to work with for journals, and I find separating them out is easier for various completion frameworks to handle rather than co-mingling them with other files. After all, today’s journal is very relevant. Tomorrow’s much less so. Even less before that. And on and on… No need to have all the clutter if I don’t need it.

And with just that, we’ve got a perfectly serviceable digital journal that I can copy, paste, and link into/out of which I interact with each morning and night. Not bad for minimal effort (though I’ve implemented enough PKM’s to know this is an easy case).

A huge but not-so-obvious reason we tackle this use case first, is that daily journals create space for process that helps fill any gaps in the rest of our setup. With a simple checklist as part of my evening journal, I can remind myself to do all kinds of things at the end of the day.

Maybe I need to do something manually for a half-baked process I didn’t finish. Maybe I need to reflect on if a piece of tagging overhead I added is still worth it. Maybe I need to scan Snipd for any useful clips rather than try to figure out a Rube Goldberg integration with it. Whatever the needs are, starting with journaling gives a regular means of repairing or revisiting any issues that might arise as we build out BASB.


There are approximately a hundred different ways to model a project in Org mode. I’ve already iterated through a few approaches, but rather than catalog each one, I’ll just detail where I’ve landed for now.:

This approach distributes all the projects in their various areas, but allows me to see any I’ve committed to through the agenda.

The challenge I ran into next was what to do about the (rather large) pile of someday/maybe project ideas. Stored in their own Area and Resource sections, they seem too disparate and hard to visualize together. Stored in the projects section they could be prioritized, but would quickly get blurred into mush.

Surely there was a way to keep the entries nestled in their Areas and to still see them fairly grouped together? Do I turn to alphapapa, his name be praised?

In short, yes. Enter org-ql. While it seemed like overkill to figure out a view to pull all the projects together, this is a great tool to auto-group by category (which I’ve added to each Area) and see all the relevant info.

TODOs for each project are kept somewhere under the project header. One section I use a lot that borrows from the BASB course is the Intermedite Packets section. Its headlines are like discrete sub-projects but with a more targeted focus to a discrete, deliverable unit of work. It helps a lot to crystalize a bigger project into smaller chunks. That said, I’ve noticed I have to be careful not to be too beholden to the list. Otherwise the uninformed me of the past might boss around current me into IP’s I discover aren’t the right things to do first once I get going.


Hand in hand with projects, of course, is TODOs. Org supports these natively, so there isn’t too much to cover given the above, but I’ll call out the interesting pieces.

The big trick is that is one of the three files I have Orgzly paying attention to on my phone. This lets me use the widget to see upcoming TODOs, capture them on the go, and get alerts on my phone base don the timestamps. I do add to and update TODOs from my desktop as well, so I need to be a little careful when syncing, but Nick Anderson points to a way to use Tasker to kick off an Orgzly sync on screen wake, and that’s pretty much kept everything running smoothly. Even if issues do pop up, it’s very easy in Orgzly to reset by force pushing or force pulling, depending on which is best.

I do occasionally forget to save a file (particularly from the agenda), so I’ve added in auto-save for buffers that aren’t saved after 60 seconds.

Most of my TODOs live in that file. However, I also keep TODOs in my projects as well. The PARA file is already in the org-agenda, so the only drawback is that those don’t sync to mobile. Currently, I’m ok with that, because if I’m being honest with myself, I don’t do that kind of work on my phone when I’m out and about. A key insight of David Allen’s Getting Things Done is that we do some things best at particular times and contexts. I find a lot of people in the PKM space try to stuff everything into mobile when they really won’t get much productive output from it. It’s a classic 80/20 issue. If there is a task I do want to stew on while I’m about, I can either find it in Orgro, or copy it into my file as a one-off, though that case so far has yet to actually happen.


Time for contacts!

Now, unlike most people who get elbow deep in emacs land, I’m not interested in bringing everything under the sun into org mode. It could theoretically be useful to have all my contact data in one place, but Org mode doesn’t plug well into non-emacs systems. My email client is GMail. Google Contacts syncs to my phone without issue, and it’s nice to see names when people text me. I don’t really need to tinker with caldav and vcard import/export because those parts are working fine right now.

What I do need from a CRM (contact relationship management system), is the following:

There is a contact management thing for org called org-contacts, but more than being under-documented, it doesn’t seem to help with my core user journeys above. I don’t really care (for now) about storing contact info in different ways. I don’t need it to play nice with mu4e or other emacs email clients. However, the idea of all the contacts in a single file does make sense to me in the vain of being as simple as possible.

So, my current flow looks like this:

A lot of those edges are a bit manual and could go wrong, but for the contacts I care most about right now it’s working well enough.


One of the things I’m working on in my life right now is cooking. I’m trying to get good at it both for fun and for feeding my family. The big key seems to be iteration, and iteration is best done with notes!

I broke out recipes into its own file from the start, because I sensed it would be big and unwieldy from the start. The Top level headings are:

Each Recipe is a heading in one of those groups with notes on the background and research, my own shorthand for the recipe, and a section for Experiments which are all preceded by a timestamp. Experiments all have sections for Notable changes, Results, and Things to Try Next Time.

Style Inspiration and Thoughts


This is possibly the most undefined use case thus far.

CODE Breakdown

While I think the use case by use case breakdown is a better framing and more informative than purely looking at the CODE framework, I thought I would run through it here should there be any interest from the BASB community.


Breaking down capture by type of information source:


This is mostly covered elsewhere, but I try to stick to one PARA file if possible, and bud off pieces that should be separated for programmatic reasons, or if I know they’ll be really hairy sections (work, Recipes, etc.).

I do want to add that org-roam is amazing for being ID based, which allows for incremental change when using it. Other similar tools require going a bit more all in on their preferred file structure. I like that org-roam doesn’t.


I tend to blend some beliefs from Zettelkasten into this step, rather than adopt Tiago Forte’s approach wholesale.

I don’t think highlighting is especially valuable as a practice, even when I was using Evernote. Even in an iterative fashion, I just found it didn’t resonate with me.

That said, I do think that rephrasing in your own words is super valuable. The whole idea of fleeting notes > literature notes > permanent notes is leveraging the power of your own interpretation to make the information more yours. I don’t see a reason to put that step off like Tiago does.

I’ll often use a << to denote personal thoughts as opposed to a good-faith transcription of ideas when I’m taking notes. I might want to tinker with a personal summary at the top at some point… but in either case I wholly embrace getting to the part where I rephrase things, rather than waiting for multiple passes at the material.


This is a tough area for me, but I’m working on a few avenues for it.

First, there’s this blog! It took a while to get around to setting up ox-hugo, but now that I have I’m very happy with the outcome. I’m hoping more personal blog posts will be on the way.

Second, part of my Stoic practice is to read r/Stoicism and respond to someone who’s asking a question every morning. I actually use the reddit app to scan the posts, but then I’ll use redigg to pull in the actual text and write a response in org mode. Then I’ll convert via blackfriday and paste it back to reddit. I’m hoping to add these posts to my own blog at some point, since I don’t like how siloed they are in reddit. The recent API fiasco might break this flow soon.

Third, I’m working on a few work projects that involve research and expression. I won’t go into them much here, except to say I’m using all the techniques I’ve mentioned so far to try and build a better public understanding of Dynamic Observability.

Building My BASB in Emacs - 2023 Capstone Report series

  1. My Path to Org Mode
  2. Should You Choose Org Mode?
  3. What Makes Org Mode Hard for PKM
  4. My BASB Implementation in Org Mode v2023-06
  5. Things Left Unimplemented… and I'm Unsure if I Ever Will