Refactoring the shadowmaker has become a bigger headache than I had originally anticipated, but it’s for the long-term health of the system, so I’m sticking to my guns. This weekend added further drama when I finally stopped running away from frontmatter and embraced it for all my metadata. Sure, scattering #ch-command directives throughout the body of the notes was insane, but fixing it is going to mean more than just adding a few metadata fields. I may have to completely change the way I use Obsidian.
The rules of engagement for the new Creativity Hacker site are still evolving, and today I’ve identified a use-case distinction that I haven’t got a specific solution for: status updates vs issue journaling.
◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇
So far, I’ve been seeing update posts as quick jot notes about what I did today on a given project. Dear diary, today I bolted the gamston onto the laggaslom. Everything looks zuggly. For people following a project, these serve as individual bloops on a protect’s heartbeat monitor, telling you that it’s still alive.
But lately I’ve been noticing that many of these posts have been about new problems I’m confronting with the project. No longer simple and self-contained, these posts open a can of worms that will likely dominate that project’s feed for an extended period, as I continue to investigate, brainstorm, experiment, and grumble.
When I started writing this post, I thought it was going to be about how some posts might become problem logs - living documents that got extended every time I made progress on that front. But the more I think about that approach, the less I like it. Yes, it would package the history of a single problem in one tidy locus, but it isn’t very flexible. A single experiment in the lab might touch on 3 or 4 different problems, so would I have to update all of the ongoing problem logs? That would be insane.
So instead, I’m going to lean into the tagging system. When an update post suddenly rears up into an ongoing issue, I’ll just give it a representative tag name and start tagging all subsequent (and previous) posts that touch on it with that tag.
With a tag-based taxonomy, I can still keep each post short and well-focused, but I can also review the history of an entire problem by assembling a log of all the updates that touch on it.
This raises two questions I’ll need to address:
-
I need to add a simple “log statement” to each post so that summary views can be presented in a more concise format.
-
What is the naming scheme for these problem-threading tags?
Log Statements
These will go at the top of each note, immediately under the Tags line, and be indicated with Log:. The shadow maker can then pull them out and make appropriate use of them in displaying the site, but I can still see and use them in my Obsidian system.
Tag Names
Each issue will have to be assigned a unique identifier name, and in order to differentiate these tags from more the general thematic tags already in use, I’ll give them an appropriate prefix. Not problem. Not issue. I’m currently focused on problem logging, but I can see how this technique might be applicable to other dimensions of effort as well, so thread captures it nicely.
And there is no better issue to start with than the one I opened the other day: The Note and Tag Pipeline. Henceforth, updates related to that will be tagged with thread-tagpipe.
