Cleaning my Closet

As an author, there are days where it is difficult to write. If you’ve been reading the blog, you will see for me there are many more days where “writing is too hard” and I do other things. I’m slowly grinding through the Luctation rewrite, and hit a bit of a wall with a subplot that needs content. Rather than face the need to create, I turned to “comfort food” of managing the business of writing. After all, I am a project manager by trade. The problem is I have a nasty habit of keeping everything in my mind.

I’ve discussed using GitHub to manage the book project. Given that GitHub manages itself using GitHub, as an author, I should be able to manage much of myself via GitHub as well. At some point, I may have someone helping me. However, right now most of the business is in my head. Why not export what’s in my head somewhere useful? Great idea.

This weekend, I started the process of documenting business content that is in various places. For example, work on the Postal Marines book covers is buried in email, the website where I found the author & designs, and the story of the covers in my head. There are a lot of different ways I could go about capturing this content. I could put it in a Word or Google Doc, store it in Evernote or—or, I could just use GitHub.

In GitHub, I have an organization dedicated to both my business and content creation. The platform provides Projects to organize & prioritize work. My effort is less about prioritizing and more about organizing. Organizations can have projects that link to several of its repositories. So I can have a project on managing book & story creation that links to the two novel series I am working on. I can have another project on managing my communications channels, stage audience engagement content, etc.

As I unified the projects, I also harmonized them with the business plan. The plan itself goes back nearly a decade, and carried its own cruft. By working these, I narrowed down the number of projects (5) that I needed to manage the business.

Tracking Book Production

I’m tracking each book as an Issue in its series repository, associated in a top-level Organization “Book Production” project. I can journal progress in the book. Or, in the case of the historical information on covers and editors, I can capture relevant content from emails, websites and my brain and tie it to each Issue. I’m on the fence about whether this should be captured via Issue or as a separate book page. The problem with GitHub Issues is they are proprietary. However, there is a project that exports the issues as markdown into a repository. Project information is rudimentary, essentially adding state to an issue, so it is less important that I grab that than the issue itself. I’m listing my editors and artists as tags, so when I export they will be captured as well. Given my pace is a book in a few years, the cadence does not justify the use of Project like this. For now, this is an experiment.

Within each book issue, I included what I paid for editing and covers. It occurred as I write this that I should do that via the book’s metadata, which I can pull out. However, a bit of redundancy never hurt anyone.

Tracking Ad Copy, etc.

If you’ve listened to Chris Fox, he talks about marketing. Included in his talks is the need to run ads and experiment. Having a repository dedicated to Marketing should help track different ad runs, etc. This would work for newsletters as well by keeping a copy in the repository instead of your Newsletter platform of choice.