A new publishing workflow for Practicing Ruby


My main goal for Practicing Ruby in the next few months is to gradually get us back on an every four week publishing schedule.

In order to do that, I’ll need some sort of plan that will encourage us to keep collaborations rolling so that we can always have something ready to publish even if each individual work takes an unpredictable amount of time.

The traditional approach to this problem is to put all of the pressure onto the contributor, overbook work in the hopes that some contributors will deliver on time, and throw in filler content when they don’t. This is a miserable process though, and it won’t work for Practicing Ruby.

I want my publication to be the most contributor-friendly place in the entire world for practicing developers to share their work. I want the process to be enjoyable for them, while also encouraging them to produce their best work. To do that, I need to create a flexible publishing schedule that supports our collaborators while still giving some consistent timing to our readers.

Although this will inevitably require tweaking, here’s the six stage process that I think will get us to where we want to be.

STAGE 1: Prospective project

I can have as many works in this state as my budget allows for. Right now I’m sticking to about half of the works that will be funded by the Kickstarter money, because I plan to do an open call for the other half.

During this phase, no schedule is set at all and the only agreement between me and the collaborator is “Yes, we’d like to work with each other.” At this point, the collaborator will know what our compensation is like, what level of support to expect from me, what the basic process is like, etc. What we won’t know is exactly what we plan to work on together and when.

STAGE 2: Accepted project

This stage begins once I’ve sorted out a specific topic to explore with the collaborator and discussed enough about it that I’m confident the topic will be a good fit for Practicing Ruby. At this point, if there is an open slot to begin the work and the collaborator is ready we can start right away, otherwise we’ll discuss a tentative start date and pick things up again at that time.

STAGE 3: Work in progress

I’m going to try to limit this stage to a maximum of three articles at once. This is not a high intensity rush to produce a work in a tight timeframe, but instead a commitment to make regular progress on the work until it’s ready for publication. It starts with note taking and conversations, progresses towards example building and experiments, and may include some rough drafting or outlining.

I am often the bottleneck in this process, and I’m going to try to reduce that in the coming months. However, the basic idea here will be that whenever I’ve passed feedback or ideas back on to a collaborator, as long as they work on those tasks within a week or two, the project stays in an active state. If someone ends up not responding for a while or it’s clear that they’re too busy to keep moving things along, the work will temporarily be pulled out of the “work in progress” queue, but can be reactivated whenever there is an open slot as long as both me and the author agree to resume work on it.

If a project has been in a work-in-progress state for more than 90 days, that’s a warning sign. When that happens, I’ll work with the contributor to figure out what is blocking progress, and then decide what to do about it. Although this isn’t technically a problem as long as we’re not blocking other projects that could be worked on, it is something that we should at least look into in order to prevent works from getting into a stalled state indefinitely.

STAGE 4: Drafting

I will typically limit this stage to a single work at any point in time. This work still counts as a work-in-progress, so at most we can have two articles in the developmental stages and one in the drafting phase at any point in time.

This is the time in which the actual article gets written and revised. Some things will fly through this process, others will crawl. Sometime the collaborator will want to write the draft, and that’s something worth trying out when people are up for it and think they can write in a way that is compatible with Practicing Ruby’s style. That said… I expect many of our collaborations to rely heavily on me during this stage of things. This both takes the burden off of the contributor and helps me maintain a consistent style for Practicing Ruby.

That said, the drafting stage is a collaborative process that the contributor actively participates in. Even when I write a draft, I’m usually reconstructing conversations and ideas that originated with the collaborator, and so I want to make sure that whatever I write up ends up reflecting their thoughts and unique perspective on their topic area. It’s the collaborator’s name that goes on the article in the end and not mine, so it’s my job to make sure they are happy with the end results.

STAGE 5: Review

If we had a traditional publishing process this would require a lot more time, but because we continuously share ideas, code samples, and excerpts with Practicing Ruby’s readers via Slack and Discourse during the whole collaboration, we will have already received a ton of feedback by the time an article is content complete.

This stage is more of a spot check on the finished work and a last opportunity to catch problems before the article is published.

The article will sit in this state for a minimum of seven days before being published. If there is already at least one other article in a publishable state, the review phase can be extended as long as time permits.

Stage 6: Publishable work.

This is the point where the article is “good enough to ship”, and it will most likely be released at the next available date onthe release cycle.

If and when we reach the enviable state of having a backlog of publishable works, there may be some reordering of publishing dates based on what would be best for Practicing Ruby’s readers (i.e. I might not want to publish two similar articles too close together, or something like that), but in general I don’t ever want an article to be collecting dust for too long.

Even though Practicing Ruby articles are meant to last for years, I will try to make sure to release a new work within 2-3 months at most by the time it reaches the publishable state.

But again, given the overall challenges in keeping a publishing pipeline flowing and the anemic state that our current schedule is in, we will most likely ship works very soon after they’re ready.

And there you have it! A plan that will hopefully get us back on an every four week publishing schedule by the middle of 2016. It’s not bullet proof and some variables will inevitably need to be tweaked, but it’s an actionable plan nonetheless.

Here’s hoping for great progress on Practicing Ruby in the coming months!

Want to collaborate with me on a Practicing Ruby article?

Email gregory at practicingruby.com. You do not need to be an expert programmer or writer, as long as you have an interesting topic to explore and are serious about your work. I provide a $500 honorarium for successfully completed works, along with a minimum of five full days of my own time to develop and support each collaboration.

Practicing Ruby is an independent publication that is directly funded by its generous readers. We will never run advertisements or accept corporate sponsorship, so you can rest assured that your work will stand on its own.

Developers from traditionally underrepresented groups in technology are especially encouraged to submit their proposals. It’s an explicit goal of Practicing Ruby to make sure developers from all backgroundsare heard from, and we provide a ton of support to help make that happen.

All Practicing Ruby articles are created for the common good. Our entire archives are publicly available under the Creative Commons CC BY-SA license.