The O’Reilly MySQL Conference & Expo 2010 Call for Participation ends in just under 3 weeks. I am on the conference committee, and thus get to see and review all the conference proposals.
This blog post will briefly explain the how each part of the proposal is used, then have a list of what not to do in your conference proposal, and end with a checklist of questions to go over your proposal before submitting. Click here if you want to skip to the checklist.

The proposal has several parts.
Title: This is the title of your presentation. This shows up on the schedules (online and print).
Description: This description appears in the conference program, and on the online session page.
Topics: These are the tracks that apply to your session. Sessions are shown online by time slot (the schedule), and by track.
Session Type: what type of session you are proposing. Most folks will propose a 45-minute conference session.
Abstract: This shows up only on the online session page.
Audience Level: Who the material is intended for
Additional notes: This is only seen by reviewers.
(and then you go on to add speakers)
Even if you are a veteran speaker, it is important to know what this all really means in terms of writing a good proposal. For example, only the title and speaker(s) show up in the online and printed schedule. The description shows up in the conference booklet, and the abstract only shows up on the web page for that session.
With that in mind, how not to write a good conference proposal:
Have a vague title
Last year, I gave a 3-hour tutorial entitled “Understanding How MySQL Works by Understanding Metadata”. My first title was “I never metadata I didn’t like.” I still think the first title is awesome, but the conference organizers contacted me and said that the title was hard to understand if you were not a native English speaker, and said absolutely nothing about the workshop.
Remember that the title and speaker is the only information that shows up on the online and printed schedules. When someone is rushing from one session to another, they may only look at their schedule. Will your title remind them what your session is about? The first title I tried to use would only evoke “that one about the metadata” — which might not be enough information. The title that I changed to is much more descriptive, and would evoke “that one about using metadata to figure out MySQL internals”.
Have an unbelievable premise
If you claim something difficult to believe, such as “The new Connector/Fast will speed up every single MySQL query and can be used in Java, PHP and .NET environments”, be ready to back it up. In the “Additional notes” section, provide pointers to websites, documentation and benchmarks so we believe your claim. I would hate to miss out on an awesome product because it seems “too good to be true”!
Short description or abstract
The description and abstract are how the conference committee members are going to be convinced that you are going to present a good topic. If your entire proposal is:
Title: MySQL Performance tuning
Description: This presentation will take you through how to configure MySQL for the best performance. Overall MySQL options and specific MyISAM and InnoDB options will be discussed. Learn how to configure MySQL in the best way for your environment!
Abstract: This presentation will cover how to tune MySQL. It will also point out the many tuning possibilities that can be done while the server is running and do not require a restart.
As a conference reviewer and an attendee, I have no idea if you have any grasp of the subject yourself. As a conference reviewer, I want to approve good sessions. The presenter may be an expert, or they may be a someone using the information they found by doing a Google search on “MySQL performance tips”.
As an attendee, I would trust that this session delivers what it promises. If it does not, I will be disappointed and frustrated.
Too much (or too little) material
The previous example promised to deliver a lot of material — tuning MySQL in any environment is a lofty goal. That is definitely too much information for a 45-minute presentation.
If you have even a small question as to whether you have the right amount of material, start outlining specifically what you want to cover in your presentation. You could actually start making the slides, or you could be slightly more vague. If you were the presenter of the previous example, thinking about the presentation might go like this:
–MySQL system variables
— with explanations of what they do
— how to tune them (ie, what values are accepted, how to figure out what values are good for you)
— the related status variables to see if you need to tune them
That seems short, but there are over 250 global system variables. Even if you were only explaining the system variables, not the status ones, that gives you 10 seconds for each variable, for a 45-minute presentation.
Sales pitch
If you are doing a presentation about using a particular technology, make sure it’s not a sales pitch. If you want to do a sales pitch, do not submit a proposal. If you are part of the company that owns the product, particularly if you are high up in the organization or in marketing/sales, co-present with an *independent* technical person, and talk with them about what people want to learn about your product.
For instance, the presentation could explain the high-level details of how to install and migrate existing data to your product — for a new storage engine, it could be “install the binary provided, then install the plugin with 2 MySQL commands (no need to restart MySQL), then use ALTER TABLE to convert an existing table to the new storage engine.” Or it might be “Export all the data with mysqldump, install the binary, import all the data using tool X”.
Have a vague description
If your session is accepted, it has to compete with up to 9 other sessions in the same slot (plus the desire for a nap and conversations with fellow attendees). If your title and/or description is vague, people are not going to know if your session is something they should attend. For example, here’s a sample (made up by me) bad title and description:
All about MyISAM
In this workshop, attendees will learn all about MyISAM and what it’s good for. This often-overlooked storage engine is really powerful in many situations. Find out tips and tricks for high volume MySQL usage, and where MyISAM can be used with better performance than InnoDB.
Who should go to that session — developers to learn about how to write performant MyISAM queries? DBAs to learn about performance tuning and debugging for MyISAM? DB Architects to learn about how to create optimal schemas (including indexes) for MyISAM?
If I did not know anything about MyISAM, I would have no idea if I should go to that session or not.
After you write your proposal, put yourself in the mindset of a potential attendee. What do you need to say to him/her to get them to understand that your workshop will help them? If you have a general topic, such as in the example above, your potential audience is all those folks who hear “Use InnoDB for everything.”
Put specifics in the description, like:
Even though MyISAM has table-level locking, it is actually more performant than InnoDB for a high-volume logging table.
See how that gives you a specific use case? A potential attendee with a relatively closed mind will gloss over the original description, because they think “Eh, MyISAM is only good for reporting queries, and I have a lots of short queries.” With examples such as “for a high-volume logging table”, this potential attendee will think, “Oh, I have a few logging tables that are InnoDB, I’ll go to learn how MyISAM could make them faster!”
Either that, or “That’s not true! I’ll go to the workshop to prove to them how wrong they are!” and be pleasantly surprised when they learn that yes, it’s true, MyISAM is better in that case.
Non-meaningful statements
Often, attendees read the session descriptions when they’re tired or rushed. Try to put the most important information first — otherwise people might get bored because they are not reading anything useful. For example, a description for a session on query optimization may start with:
Everybody wants to increase query performance, but in reality there is no one way to make every query faster. Server tuning variables can help. The real power is in optimizing the queries and the schema.
Compare that to the following sentence to start the description:
Optimizing the queries and the schema is the most powerful way to make every query faster, though tuning server variables can help in some cases.
(note that both these descriptions are not good as *complete* descriptions of a session. But cut out all the junk up front. If you end up using words like “obviously” or phrases like “everybody wants” or “everybody knows”, chances are you can probably delete the entire sentence.)
Assuming you are well-known
Perhaps you are famous in the foo community, and are doing a presentation on how to use foo with MySQL. The conference committee, and the conference attendees, may have no idea who you are. Or worse, they may have been exposed to an early work where you made some mistakes, and have a skewed view of your knowledge level.
For instance, if someone was exposed to just a few blog posts I made, including one I made early on that made a suboptimal recommendation, they might think I know very little about MySQL.
Assume that your proposal is all that the conference committee knows; put information in your bio and the Additional Notes pointing to your blog, previous presentations you have done (at places other than the MySQL conference), and other sources that will show that you can do a good presentation on your topic.
Before you submit your proposal, ask yourself:
0) Will non-native English speakers understand my title/description? Being funny or cute can backfire; if you want to make sure you get the joke in, put it later in the description.
1) Will someone who has just “heard of” what I am presenting be able to figure out from the title and description if they should come to my talk?
2) Is my topic too long or too short for the time allotted (45 minutes for most sessions)?
3) Have I shown the conference committee that I’m knowledgeable in the subject, and that hard-to-believe material is true? If not, use the Additional notes field for information you want only the reviewers to see. If you have a demo or draft (or more!) of the presentation, put it on a web site somewhere and point reviewers to the URL they can access.
4) Can I write down points people will learn from my session? For a 45-minute session, try to write down 10 points. For example, Want faster queries? has a very short description, but the abstract itself is a list of 6 bullet points, and the last bullet point “Common mistakes” can easily be turned into the 4 most important mistakes people make.
5) Will someone who has 5 minutes to decide on and get to the next session be able to make a good decision on whether or not they should go to my talk based on the title?
6) Have I gotten rid of statements and introductory phrases/sentences that have very low meaning?
7) For presentations about technology you work on, is the presentation suited for DBAs or developers? A presentation should balance “why you should use this” with “when not to use this” and “the problems you might run into”.
8) Is it clear to a person who already knows most/all the information in my talk that they will *not* be interested?