NoRedInkers love submitting talk proposals to conferences. It give us the opportunity to share our ideas with larger programming communities. That earns us valuable feedback, plus offers of help and support.
That’s the easy choice. The hard choice usually follows: “What do I say in my proposal?” I have reviewed incoming proposals for four conferences now, so let me share some quick tips based on what I have seen.
There’s No I in A-B-S-T-R-A-C-T
Ban the word I. Also we, me, our, etc. In other words, don’t talk about you.
You’re building a talk for the attendees. Talk to them. Tell them why they should attend your talk and what they will learn from it.
This is a key point that should ripple all the way up to your selection of topics. Are you considering giving a check-out-my-library talk? Vetoed. (Did you catch the problematic word my there?)
Now, that doesn’t mean you can’t give the talk you want to give. You just need to work on your framing. It’s totally valid to show some problems that attendees commonly face and then tell them how your library can be used to solve those problems.
Just remember, the talk is about them, not you.
Strike While the Iron is Luke Warm
If we define iron as the servers hosting the Call For Proposals (CFP) form, then they are plenty cool when the call opens and in danger of catching fire when the buzzer dings. When I was on the program selection committee for RubyConf, we received a little under 400 talk proposals with over 100 of those coming in during the last three days of our two month call.
Try not to be on either end of that range. If you’re too early, your talk could feel like old hat or be forgotten by the time the important decisions are being made. Being at the end is far worse. When a CFP closes, the pressure is on to get the acceptance emails out as soon as possible. All reviewers want to believe we’re as fair as possible, but the reality is that you won’t get the same treatment when you’re the 30th proposal I read that day.
Don’t raise the bar on how much better your proposal will need to be to get accepted. Aim to be in the middle of the call window.
The Goldilocks Zone
Most conferences provide a reviewer’s eyes only field for elaborating on your plans for the talk. This is often called something like Details.
Deciding how much information to include in this field can be tricky. You need to give reviewers a feel for what you want to do, so they can get behind the idea. However, they have to read a lot of proposals and you need to respect their time as well. You don’t want their first impression to be, “Ugh.” Like Goldilocks, you want them to think what you included was, “Just Right.”
Do not summarize your entire talk in this field. It’s too long and you’ll probably change some bits before you give it anyway. Just don’t go there.
An outline is probably the best detail you can include. That gives an overview without going too far. It’s probably also worth explaining, in slightly more detail, the main points or examples. If you feel like you need lengthy background material or chunks of code, provide them as links so a reviewer can choose how much they want to dig.
Bio-ology
I have just a few pieces of advice when it comes to writing a strong speaker bio:
- Tailor your bio to the specifics of your talk, like you would tailor a good resume to the job
- Sell the reasons you are qualified to give this talk and skip any perceived weaknesses you feel compelled to mention
- Add a dash of humor
- Avoid mentioning identifying information (including GitHub repositories) outside of the designated bio field in case the conference organizers use a blinded review process
Main Title
I’ve asked, and been asked, if a clever title matters. Answers vary, but one thing is certain: it rarely hurts.
If you’re introducing Powerful New Techniques, then a self titled talk is probably fine. Otherwise, I would put some effort into finding a title at least as clever as the subtitles of this blog post.
Good luck with your submissions. We hope to run into you at future conferences.
