I’m on the MySQL conference committee again this year, so I’ll be reading and voting on your session proposals. My past experience is that reading 400 session proposals is a mind-numbing job, and I will be optimizing it to save my time. That means I will be scanning your proposals and deciding very quickly how to vote. I wrote before about how to submit a great proposal, but I’ve refined my opinion since then. Here are my suggestions:
- Write for two audiences: reviewers and attendees. Both of us want the same thing: to decide as quickly as possible whether your session will be good.
- Write a strong title/headline. Don’t know how? Here’s a good start. The title or headline is your best chance at getting accepted. But don’t be too clever.
- Make it short. Please! Your description should be a few sentences, and your abstract should be a couple of paragraphs. If you think you need more than that, you need to learn how to write succinctly. Tutorials can be longer.
- Avoid being cute. No puns on programming languages, for example. No matter how funny you think it is, just get to the point. People can appreciate your wit in person.
- Get it right the first time. You can go back and edit it later, but I will not be re-reading and re-voting. If necessary, get a trusted friend to edit your proposal before you submit it.
Don’t lead off with generic or banal truisms, or set up a “describe the problem, build the suspense, dramatically introduce the solution” dynamic. It doesn’t work. With due respect, this example from last year’s conference is a study in what not to do:
With the increase complexity of software architecture and database design the amount of data stored in databases systems grows rapidly. Additionally, data security and international regulatory laws require that data changes are audited and restorable to any point of time. The revision engine implements automated auditing of data transparently as a storage engine.
That proposal wastes the first two sentences stating obvious things, instead of talking about the session itself. It is asking too much of the reader to plow through all of that. The proposal should get to the point: “The Revision Engine automatically saves all old versions of your data…”
- A cool topic cannot save you. You have to demonstrate a clear thought process with a well-written proposal. If your proposal is badly written, I have no choice but to believe that you can’t create and deliver a good talk.
My suggestions from the 2008 year still stand, too:
- I will not give you a favorable vote because you or your employer are famous. Your session proposal has to carry its own weight.
- You need to write a detailed enough proposal to convince me that you’ve put some effort into it. I won’t vote for “accept this talk, and then I’ll fill in the details.” Do the work and take the risk that you won’t get accepted — protecting yourself against rejection is a good way to get a low vote from me.