Retirement Planning

/images/_77125065-618c-4496-bb75-fc28f42d61ce.jpeg

So far, the emphasis has been on managing active projects, but what happens with a project when its active development phase is over? It either goes on stage, or into a box.

◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇

So far, I’ve identified four categories to consider:

  1. projects that are done and released, such as a book or game

  2. projects that are completed to my satisfaction, but are not being formally released

  3. projects that are on pause but that I intend to return to later

  4. projects that I’m abandoning altogether.

Abandoned Projects

One of the sad truths about experiments and creative projects is that they don’t always work out as planned. Maybe I discover that the cost of completion is too high, or learn that there’s a better solution already available, or possibly the idea just doesn’t work as hoped. But for whatever reason, I sometimes need to box up a project and stick it in the attic.

I don’t want to delete it, because the journey is half the fun, and I want to leave the record available to anybody else who might explore a similar idea later. On the other hand, I don’t want it cluttering up the active project area either. So I need a new section of the site where these projects can be moved. For obvious reasons, I’m calling this area the attic.

Important Note: The attic will be accessed through a different part of the site navigation menu, but the URL path to the content will not change. That way, external links to the project will not break.

In-House Projects

Some projects are completed successfully but produce no real deliverable. I need a place on the site to move such projects so that the history is all still there, but they’re not getting in the way of the active stuff. Still accessible if I want to play with it myself or show it to friends, and out from under my feet, but not as inaccessible as putting it in the attic.

That’s why I think of these as being in a box in the basement.

Released Products

Many of my projects produce a shareable product as their output. Books and games are obvious examples, but it could also be a design plan, a series of videos, downloadable software, etc. When the active development is finished, I need a way to highlight the result, so a released project needs a “showcase” display - a promo poster - and the site needs an area for displaying and organizing those posters. Additionally, the poster should have a link back to the development record, like a sort of automatic “making of” documentary.

And now that I think about it, the only difference between an in-house project and a released project is the presence or absence of that showcase page. Records of completed projects of any kind should go into the basement, but only the released projects will get a poster.

Pressing Pause

The last category are the projects being put on hold. Sometimes I just need a break. Maybe I’m stuck and need some time away to regroup. Maybe I’m getting bored and need to switch to something else while my interest battery recharges. Or maybe some other project suddenly has demanded a lot of my time and I need to set the lower priority one aside.

To be honest, half the projects put into this category never recover and will eventually get moved to the attic, but half do come back into the spotlight, so the attic is too extreme as a first step.

I guess the best metaphor is that these projects are in limbo. What I’m not sure about is whether I should put them there explicitly, or whether they should crawl there on their own, whimpering, when they realize they’ve lost my attention.

I kinda think that if I have to move them manually, too many will stay in the active area even though I’m not actively working on them. So auto-pause seems like a good idea. If a project hasn’t received an update in over a month, chances are good that I’m not working on it. On the other hand, I sometimes create checklist posts and update those for a few weeks as I work my way through the list, without adding any new update posts explicit. So instead of watching for new posts, I’ll watch for the most recent edit time on posts.

Yeah, I think that captures it nicely. If I’ve gone an entire month without even correcting a typo in the update feed, that project has fallen off my radar.

Implementation

So that means I need:

  1. 2 nav areas for displaying non-active projects: the attic for abandoned ones and the basement for completed ones

  2. A way to explicitly flag a project for one of those two destinations when they’re no longer active (ch-deploy-attic and ch-deploy-basement)

  3. A way to auto-mark projects that are slipping but that I haven’t boxed up yet.

  4. A showroom system for organizing and displaying posters. (A new post with ch-showroom-roomname.)

  5. A way to add a marketing poster to a finished project. (Add a post with ch-promo-roomname) And just to be clear, a poster can be tagged for multiple showrooms.


Read More


/images/_e1b23d38-68ca-45eb-bf1b-56bd12ad0ce3.jpeg

Obsidian-fu

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.

/images/_e42c8a8a-b127-431f-b414-425c5d17a2dd.jpeg

Ontology-2.0

While trying to integrate the many episodes of CaveTV into the site, I realized that the ontology was getting cramped. It needs to be revised to better distinguish between internal projects, external brand identities, multiple deliverables within a brand, and distinct showrooms.

What follows is the scheme we devised for what the abstractions are, how they should be tagged in Obsidian, and how the files will be managed within Hugo.

/images/_2ef531ec-bc45-46fe-841b-6864301fa06c.jpeg

Cutting The Monster Into Pieces

Now that I’ve identified a useable hosting candidate, my final test of their service will be to roll out a full implementation of the websmith deployment scheme. But in contemplating how I’m going to do that, I’ve realized that I may not have broken the project into distinct repos properly. So I’m going to figure it out by explaining it to the rubber duck. (Meaning you. :-)