I’m on the select board of elite people who were duped into reviewing proposals for the upcoming MySQL Conference and Expo 2008, and I’m here to tell you how to get your proposal accepted. Aside from bribing me with chocolate, that is.
These are my opinions. Believe it or not, I have not been instructed how to evaluate proposals. And by the way, I have no authority to get your session accepted—I only get to say how good I think it is. (Maybe I should re-title this to “how to get me to vote for your session,” but that’s a lame headline).
Reading proposals is like reading resumes: they all look the same in some ways. Think of yourself as one in dozens of proposals, and imagine how they all blur together in my mind (don’t feel bad. Most things are a blur in my mind).
Don’t do a session on the same things everyone else has done. Get a feel for how hard it is to tell sessions apart by scanning through the list from the 2007 conference.
Dare to be different from what you’ve done before, too. If you are well-known for a particular thing, let someone else have a shot at it for a change. Stretch yourself. When I look at your session, and I see you’ve done it before, and I look on YouTube and there you are doing it again, I want to hear someone else say it.
I thought last year’s conference only covered a small fraction of the incredible depth and breadth of this highly technical subject. There were lots of things I would loved to have seen. Rather than name anything I want to see this year, I’ll name one of the best sessions I saw last year: Beat Vontobel’s session about the declarative nature of views, and how a view is to SQL what a predicate is to Prolog. Way different, way cool!
It is not a good idea to say “more details after you accept me.” I want to know what you’re talking about, in detail, before I will give you a high mark (we rate each proposal on a number scale). I’m trying to read your proposals from the point of view of a conference attendee. That viewpoint is “I can’t decide what sessions to attend.” Again, look at last year’s conference schedule and see what it was like.
Remember to make the first dozen words or so of your proposal give a compelling reason to keep reading. That’s how conference attendees will figure out which sessions they want to attend. It also makes my job easier as a reviewer.
General sessions are good, but I would also really like people who are stark raving experts in something or other to blow my mind. But don’t be arrogant, and don’t expect your name to carry more weight than how specific you are with your description. Enough said.
There are lots of people who haven’t heard introductory topics before, so I’m keen to vote for sessions about basics too; I don’t want this to be an elitist conference that doesn’t help people who haven’t been working with MySQL for a long time. Again, specificity is key; If you tell me specifically what your intro session will cover, I’m going to mark you higher than someone who just says “this session will cover introductory topics on transactions and SQL commands.” Specificity helps me figure out who’s going to do the best job with the sessions I don’t want too many of.
People who are “seasoned veterans” often have a lot less to teach me than newcomers to MySQL. Old-timers get stuck in their ways of thinking. I need to see things through a newcomer’s eyes to really learn things sometimes. So if you’re new to MySQL, please submit a proposal!
If you’re going to submit a 3-hour session, you should give enough detail in your proposal that I can judge how good it’s going to be. Three hours is a long time, and the stakes are high for you, for the conference, and for the attendees. You should be covering something in great depth. Tell me what. Just as an example, if you say you’re going to walk attendees through building a sample application, tell me what the application is. “Sample application” is not sufficient.
The proposals I’ve seen for 3-hour sessions so far are about the same length and level of detail as the proposals for 45-minute sessions. That’s not enough! It needs to be about 4 times as long and give about 4 times as much detail. In my opinion, 3 hours is too risky to grant someone without knowing that they’ve done their planning and homework. Again, these are only my opinions.
Your biography is displayed right below your proposal. I look at it when I rank your proposal. Convince me that you are qualified to give the session you’re proposing (without being arrogant, of course).
Some of the best biographies are the shortest ones. Not to pick favorites, but here’s a good example from last year:
Petr Chardin authored MySQL server log tables. While working for MySQL he also authored MySQL Instance Manager cross-platform server, which serves for remote configuration and management of database server nodes. Petr lives in Moscow and works for Google.
That is a good bio, but not because Petr used to work for MySQL and now works for Google—it’s good because it gets to the point right away and has zero fluff.
This year the conference is using different organizing software, and you will have the opportunity to edit your bio. Do it—it will make people want to come to your session more. (Last year someone chose my bio for me and I wasn’t able to get it changed—so please don’t use my bio from last year as an example!
Did I mention it’s probably cheaper to attend the conference if you’re a speaker? Last year’s conference was free for speakers, I believe. I have no authority over this, so maybe this year it won’t be. I’m sure someone will fill in that missing information. Hint, hint.
Don’t pay attention to me
This is the first time I’ve ever done this, so I don’t know what the heck I’m talking about. Jay Pipes or someone else from MySQL is likely to correct this blog post.
I look forward to seeing your proposal, receiving chocolate in the mail, and marking your proposal as “Great.” Just kidding! I actually look forward to seeing you at the conference. Remember—you only have a few more weeks to submit! Get crackin’ now so you can plan something great and write up a killer proposal.