Over the past few weeks, I’ve had the privilege of reviewing over 450 proposals submitted for RailsConf and while it was a lot of work, it was fantastic to read everyone’s ideas and submissions. A conference speaker myself, I know it takes some amount of effort to submit. There are many who spend hours reviewing and revising their talk proposals, agonizing over the word count and how to present a compelling case and story only to send it blindly to a group of people to discuss. You have no idea what they’re doing or saying. Sometimes you receive feedback and sometimes you don’t. Then you just wait and wait and wait, hopefully for an acceptance, but sometimes, often times, for a rejection. So first and foremost, I want to say THANK YOU to everyone who submitted. Thank you to everyone who put themselves out there and tried to give the Rails community an interesting take on a topic they love. That being said, I did see some common threads and places for improvement. Here’s what I learned from reading all those proposals.

Proofread

You would be amazed at how many proposals are submitted with typos. Please, please, PLEASE, spell check. Read through your proposal, have a friend read it over, have anyone read it just to make sure there aren’t typos.

In addition to typos, there are a lot of abstracts and proposals that are submitted with some of the content cut off. I tried to alert most people to this fact so they could revise and resubmit the proposal. Make sure when you’re submitting, everything looks as it should. Don’t just fill out the fields, but check out the preview space that’s provided to you.

Finally, read directions… especially if you are submitting to a track. If you’re submitting to a track, check out the track details. Don’t just assume by the title of that track that your talk will fit in there. Instead think about the outline and guidelines put in place by the track curator. Even if you’re submitting to the general pool, each section has a few suggestions and guidelines about what should be covered. Please read that and follow it.

Use Less Jargon

The folks on the program committee for RailsConf come from a variety of different backgrounds and perspectives. Everyone has a different amount of tech breadth and depth. If you are using a jargon-y term, please explain it (at the very least in the details section which does not have a character count limit).

Now, what is jargon? It is anything that seems like a term other people might not know. Try having a colleague with a different level of experience read your abstract, or a friend who doesn’t work at your company. If there are words they don’t understand, then that’s a good word to define. Remember, the submission accepts markdown so if you don’t want to launch into a long explanation or definition, you can always simply link the term to a good blog post or article. Finally, acronyms are always jargon. Please write them out.

Master the Details

This is where you can really give the reviewers a good feel for your talk. If the abstract is the compelling piece that going to get butts in chairs at the actual conference, for me, the details section is all about making sure the talk will be well thought-through and presented effectively. This is a balance. Sometimes details sections can be sparse, seemingly because the submitter doesn’t want to “give away” the entire talk, other times it is very verbose going into each bullet point that will be on each slide. Most of the best proposals struck a balance between these two options.

Don’t worry about giving away your talk! We won’t tell anyone. We want the audience to attend your talk too! But we also don’t need to know every tiny detail. I liked proposals that walked me through the overall flow of the talk, the story that would be told, and offered a handful of bullet points with some broad details about either all or some of them (depending on how many bullet points you include). If you are referring to topics, tools, or concepts, feel free to link a few of those if you think they might be unfamiliar to some of the reviewers.

Pitch Yourself

I personally always find the pitch section to be the most difficult one to formulate an answer for. Please, do not regurgitate sentences from other sections for the pitch. I read the whole submission and, for me at least, when I had a lot of proposals to read through, it was wasted time and space to repeat sentences I had already read.

Here are some things that were included in strong pitch sections:

1. A little bit about yourself and why did you choose to submit this topic. Tell me a little about yourself! Yes, this submission is blind but that doesn’t mean you can’t tell me what you’re interested in both related to programming and outside of programming.
2. Feel free to mention conferences you’ve spoken at or ones you’ve attended and really enjoyed.
3. Include past slide decks or blog posts but please, use a bit.ly link or something that hides the true link. Most slide deck or blog links include some portion of the submitter’s name which is really something we try hard to avoid seeing during the initial review.
4. Tell me why you chose to submit this topic. If the details are all about what the talk will look like and what the flow will be, the pitch is about why you cared enough to work on a proposal related to this topic and why you think it’s important for the community to hear about.

Submit Early

Over a hundred proposals came in during the last 48 hours. Over 100. The fact of the matter is that even if some of these proposals are great, they get slightly less focus, less attention, and definitely less feedback from the people reviewing them. As a reviewer, being able to read a handful of proposals a day allowed me to provide better feedback, pay closer attention to revisions, and work with speakers a little more. While, of course, I still gave attention to the 100 proposals that were received later, I was reviewing many more proposals in a much shorter period of time.

Additionally, if the proposal you submitted is on a topic that got a good amount of submissions, the proposals are automatically compared to others that were submitted earlier. It’s better to use the strength of having me look at your proposal and only your proposal without being mentally influenced by other ones I had recently read.

My final piece of advice is to fill out all the sections. Please. There are only a few of them and they are all uniquely important for reviewing proposals. If you have questions about a section ask a friend, tweet at the conference or any of the organizers. We are happy to provide some guidance (or submit early and ask in the comments section).

Congratulations to everyone who was accepted. Don’t stop trying to everyone who was rejected this time around. And hopefully, I’ll see all of you at RailsConf.