How to Write a More Effective Conference Proposal

Noticeable trends and tips from reviewing over 450 conference proposals

Paper Weaving by Joel Penner is licensed under CC BY 2.0

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.


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 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.

Photo of Allison McMillan

Allison was first introduced to programming at a Rails Girls workshop after a career as a nonprofit executive. She is also an international conference speaker living in the Washington, DC area. When she’s not writing code for us, she invests her time leading the People Committee which focuses on the health and happiness of our team members!


  1. February 22, 2017 at 16:19 PM

    This was a really helpful piece, thank you for writing it! It’s nice to get an “inside scoop” on what reviewers are thinking to help me as a submitter tailor my submission to what you’d find most useful.

    This did seem very Ruby Central-specific, considering that the makeup of the CFP form varies a good deal from conference to conference (much to my personal consternation!). But at least 80% is relevant across-the-board, good stuff for me to consider.

    I’m always hard-pressed to figure out how to structure my Pitch sections, so I very much appreciate the brainstorming material here. That alone merits this post a place in my bookmarks.

    “Acronyms are always jargon” seems a bit overblown. JSON, HTML, XML, and API all come to mind as examples of things I’d never expect to spell out. And there are also things like RFC or SOLID which, given the context of the presentation, might be reasonable to expect the average attendee to know. Maybe a better rule would be “If you expect every level-appropriate listener to your talk to have heard of the term, no need to spell it out. If you’re not sure, spell out by default.”

    P.S. “a good about of submissions” should be “a good amount of submissions” (on the topic of typos…)

  2. February 22, 2017 at 20:10 PM

    Thanks! As you say, submitting a talk feels a bit like “send a proposal into the void”, so the extra information really helps out :-)