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