I’m taking a creative writing class through StoryStudio Chicago. It’s a memoir foundations class, which might sound basic, and it is, but basic with purpose.
Despite my best efforts, I quickly get dragged down into my manuscript and struggle to pull myself out and look at it objectively. My guess is that the manuscript is still too raw so I am easily transported back to events. Also possible the writing is just that visceral that anyone reading it would be transported to those events.
I don’t know if that’s a good thing or a bad thing.
One thing I do know: the me who wrote that manuscript is not the me writing this blog post.
The purpose of taking the memoir foundations course, and going back to basics, is to generate new content about this new me. This person I am becoming. I say “becoming” rather than “become” as I don’t believe the process, as it were, is complete.
There is still old code lurking within my brain. A good deal of it has been rewritten, and much of my brain has been rewired, but legacy code runs deep, and I’m not convinced I got it all.
Part of this going back to basics is also setting up my creative writing tool chain. It was a challenge trying to find the version of my manuscript that I submitted and successfully defended for my MFA, even with my well structured folders and files. Living in a Linux world, using git, GitHub, VSCode for work stuff, I wanted to try creating a similar tool chain for this class, and for my manuscript.
Except I don’t want my manuscript publicly accessible. Yet.
Creative writing tool chain
Turns out, you can create private GitHub repositories, or a central location for all your folders and files. You can create branches, do stuff like edit files, create and remove files and folders, without impacting your main or central content. For example, I can create a branch called chapter-1 and work on it until I’m satisfied, commit the changes, and merge it into main so it’s all in the same spot.
I don’t have to dig through a series of folders on my hard drive or in GDrive, and try to remember what I named a file for a particular version that I really liked, that is slightly different from an earlier version. With GitHub, if I want to see a series of changes, I can look at the commit history.
I can write in VSCode, which for some parts of my manuscript is very helpful. Save my content to the appropriate branch, merge, and push and everything stays in sync.
The challenge comes when I want someone to read it. Sure, I can invite people to the private repo, but then they have to create a GitHub account. Some might, others may not.
The cool thing
All of that is well and good, but the cool thing is being able to create a private repository, a folder in that repository for stuff I’m OK to share publicly, a public repository, and connect the two! With a little ChatGPT help, I was able to setup and configure a yaml file to automatically sync whatever I add to the folder to the public repository I created. I thought that was cool. Until I learned something better: leveraging GitHub Pages to sync the public repo to this website using a subdomain: http://public.gwynnemonahan.com/
Once the DNS has propagated (which it might have done by the time someone reads this), whatever sits in my public repo will appear.
I have some work to do to update the read and create some kind of navigation since it doesn’t have the fancy nav of WordPress, but that’s OK. More experiment!
What’s next
This feels more like a test run to see how this goes. I find myself wondering if there are tech-savvy editors out there who would read and edit/provide feedback on my manuscript via GitHub, or if that’s too much to ask.
I feel like it isn’t, and I feel like the authoring-to-editor tool chain needs an upgrade, but I haven’t gotten to that point yet.
Time will tell.