The Fireside Magazine Submissions Process

I recently had the chance to work with Brian White of Fireside Magazine on the submissions process for Issues 3 through 5. If you follow me on Twitter or read this blog you’ve heard me talk about Fireside. If not, Fireside is a fiction and comics magazine with two founding principles: good storytelling regardless of genre and fair pay for artists. To date it has published two issues, both funded via Kickstarter. I first heard of it via the mighty Neil Gaiman and his essential Twitter feed (@neilhimself), and within 10 minutes I had pledged and asked Brian if I could help with submissions.  Since then we’ve developed a friendship on Twitter, based on mutually escalating attempts at absurdities and insults. As you do.

When Brian first approached me to ask if I wanted to help manage the submissions process, his chief concern was that by funding the magazine via Kickstarter pledges, it left the magazine open to intimations that the submission process was less than honest, and that stories were placed through quid-pro-quo. He needed someone to be at the front of the process, distributing stories to volunteer readers, and then to him, so he could review and decide on stories without ever knowing who the authors were until the end. I haven’t worked in submissions before, but I work as a software engineer and before that I was an accountant, so I have some experience with information and process. So I said yes, and Brian and I came up with the following process. If you work in publishing at all, but particularly in the small indie press/magazine world, I hope you’ll find some useful nugget in what we learned.

When a story arrived in the Fireside inbox, the first step was to make it ready for distribution. We could have simply forwarded emails, but we wanted to be as careful as possible and decided to make the stories anonymous before they went to the first reader. The submissions manager (in this case, me), would have to download, make a copy, strip out names, and then forward that copy. This seemed a lot of manual labor that technology could help with, and luckily enough Fireside runs on Google Apps. This gave us the option to code Google Scripts to do some basic, repetitive tasks for us and leave the judgment to a human.

We found a script written by Amit Agarwal, which we modified, that would read the inbox every 5 minutes and do the following steps:

  1. Download two copies of any attachment, one each to the Submissions or Submissions Anon folder on Google Drive. One would be a pristine copy we did not touch, to the Submissions folder, and another to modify before distribution, to the Submissions Anon folder.
  2. Next, the email was tagged as read, and moved into the All Items folder so we would know which emails had been processed, and if the process stopped working, which had not.
  3. Lastly, we maintained a Google Spreadsheet….um…spreadsheet, that kept the following data: Email, Author Name, Document Name, Assigned Reader, and which we would also use to track status. The first three pieces of information we got from the Google Scripts representation of the email message and attachment, the last we got from a list of readers we built into the script and walked through from start to finish and back to start again. When we were ready to add the next row to the spreadsheet, we simply looked at the last row written, got the name, found it in our list, and then picked the next one. As long as we didn’t screw around with the spreadsheet, this would work well. At least until the time the script, through dumb luck, assigned an author’s story to HER ROOMMATE. Know your readers, folks.

I’ve written up a separate post on the script for those of you who are technically inclined.

At this point we switched over to manual processing. We set up a folder for each reader. If we had decided to allow the readers to strip out author names, we could have gone one step further and had the script move stories into the reader’s folders. But we decided that checking sub guidelines and making stories anonymous would be the subs manager’s job. So before I copied stories into readers’ folders, I downloaded them, cleaned them up and checked sub guidelines (word count, etc.) and the copied them out to readers folders. One thing we did not know until we started was that a) we would get a lot of .rtf files (I think from Scrivener, as a Scrivener user it looks like their templates were used a lot) and b) Google Docs does not know how to read .rtf files. So I downloaded them all, saved as .doc files and cleaned up, then uploaded. And noted in the spreadsheet that the story had been assigned, and a rough date when this had occurred. Throughout the submissions period, I would let the team know when a round of submissions had been distributed.

Next came time to deal with reader decisions. Once readers had a chance to go through their assigned stories, they were to move them into either Accepted or Rejected folders. Generally, readers had access to their folders alone, not the spreadsheet (including Brian) or Brian’s folders. The accepted stories were copied into Brian’s folders, and I noted the first reader’s decision in the spreadsheet. If the story was rejected, including from Brian, I noted this in the spreadsheet, and left it where it was until I had a chance to send emails. I did my best to stay on top of emails, but I didn’t have a very smart process at first for the emails and these piled up a bit. Close to the end I came up with an idea for how to more quickly create the form emails using a formula in the spreadsheet (similar to a mail merge in Excel), and this helped. Once an email was sent, this was noted in the spreadsheet and the copies of the documents moved into the archive folder.

There were many things that could have been done better. We had many more readers than we probably needed, which is great! The interest in helping out was fantastic. But I think as a result the reading speeds of our original team varied from “within a few hours” to “Fire-who? I didn’t ask to read this stuff”. If we had fewer readers, when submissions slowed in the middle of the period, they might have been more if they were still getting stories each day or two. Second, if we had decided to ask the readers to anonymize (screw you, Microsoft Word, that IS TOO A WORD) the stories, we could have skipped the download and upload step. And as useful as the Google Apps scripting and integration was, Google Drive was a little difficult to use for the readers. With fewer readers, I think we could have assigned them each Fireside addresses, but for a magazine as young as Fireside, I’m not sure the extra cost is worth it. That’s Brian’s business as editor and publisher, and I trust his judgment.

In the end, with a volunteer corps, we reviewed 160 submissions in a month’s time, on a system that we built in a few hours for free. Brian bought a total of 8 stories, 5 more than initially planned, and we each got a chance to help out a great project. I learned a lot, both from the reading and from designing the process with Brian, and I hope there’s at least one or two useful ideas in here for someone else. Lastly, Issue 3 is currently open on Kickstarter, so check it out and help get some good fiction published. Cheers!


One thought on “The Fireside Magazine Submissions Process

  1. Pingback: Updates! (Now with more poutine) | Fireside Magazine

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s