The sessions are expected to be technical, and I'm happy the proposals follow this guideline. I use Giuseppe's and Baron's general guidelines for submitting a proposal. I wish to humbly add a couple notes myself.
Be fairly brief
Explain your session/tutorial as clearly as you can. The reader should be able to get the general impression of the session from two or three paragraphs. Some can make a point in two sentences; for most it would take somewhat more.
If you're going to talk about some database feature, for example, please do not write the manual for that feature. That's for the session itself. Just explain how you're going to discuss the feature, and why it should be of interest (e.g. what the benefits of this feature are, the risks or pitfalls, the ingenious C code behind it or the quirks of the operating system involved).
It's important for me to understand two things when reading a proposal, which establish the grounds for better evaluating the proposal:
- Who the target audience is (newbies, developers, DBAs, Linux internal experts etc.)
- To what depth are you going to deliver the content you describe.
That is not to say you should explicitly state "This session is for MySQL DBAs", but the attendee should be able to easily decide whether your session appeals to his type of work or expertise. I, myself, have happened upon sessions that were completely different from what I expected. To illustrate, I give two examples, while not disclosing the exact details:
- A session which was about locking in database. I got the impression it was about ways to avoid locking, issues with mutexes etc. It turned out to be a discussion between the presenter and a few member of the audience about the specific code internals, lines 667-684 in the lock_module.cc file, and the recently reported bug. To me it was more like the weekly rnd meeting of some company. I couldn't understand anything of the entire talk.
- A session promising insight on working out great scale-out with some product: I was expecting to hear of the "DOs and DON'Ts", or of great configuration and implementation tricks on the subject. However, it turned out to be more of a general talk on "how we used the product in our company and found it to work great".
The two sessions above were perfectly valid, and had their place in the conference. But were poorly described in the two respects I mentioned.
A great submission, in my opinion, is one where attendees get what the expect, and don't shyly leave the conference room 15 minutes into the talk.
Submit a proposal here.