As it happens, this weekend is one of those sift-through-hundreds-of-talks weekends for me. The advice I’m about to give is therefore top of mind. Other PC members do things differently and have a different perspective, but generally the list of “do’s” and “don’ts” that are listed on the talk submission page are a good guide. I do regret not having done this after last year’s grading, but better late than never. I’ll try to link back to this post next year (if I’m still lucky enough to serve on the PC) to give fair warning. Lastly, before I get into it, be assured that these guidelines don’t talk about any single proposal. They’re from persistent patterns I’ve seen over the years. Here goes:

• If you don’t have – or aren’t talking about – source code that I can download, please don’t bother. There are obvious exceptions (talks about community practices, usability, etc.), but if you’re trying to dress up a corporate agenda about “open standards” or are trying to market a closed system that just might happen to work with some bit of Open Source technology, you’re likely to get dinged. There’s no policy about this, of course, but the PC is comprised of people who actually do think that access to source code under good terms is important.
• Don’t post the same talk to a zillion different tracks. Think hard about which track is best for your proposal, and mail someone on the PC if you’re not sure. If you can’t identify who on the Committee would be most likely to know, ask one of the Program Chairs.
• What you submit will get printed in the program bulletin if you’re accepted. In years past there hasn’t been much of a way to amend or change this, so be sure that when you submit, it’s what you’ll want people to see when they’re stumbling out of one talk bleary-eyed and choosing between tens of other talks on the fly.
• Context is important. If your presentation is about something truly ground-breaking, earth-shattering, and new, it will be helpful to the reviewers if you describe it in terms of things that attendees might already know of.
• The longer the talk you’re proposing, the more detail you should provide.
• Warmed-over talks from some conference circuit are less likely to be appealing. OSCON has a limited number of slots (believe it or not), and if attendees can see the same talk somewhere else, why should they come see you at OSCON? If you give a lot of talks, be sure to note why this talk is different.
• Don’t assume that your company’s name buys you cred. If you’re talking about something important that you have specific knowledge of because of what your company does, that tends to show up in the thoughtfulness of the talk description (or at least I tend to hope it will). It’s really embarassing when good people from respected firms don’t make the effort they should because they think that somehow we’ll assume that what they have to say is by-default important. OSCON, like OSS, is very much a personal meritocracy.
• Present something relevant. If you’re presenting a new way to do something that others have been doing for a decade or more, you need an angle on it that’s fresh or an explanation for why it’s important now. The hot things are hot, the cold things are cold, but there are interesting problems in most bits of OSS. Your challenge as a presenter is to help us understand that you think they’re interesting and that you understand that attendees might need an extra reason to pay attention to something that they might otherwise think of as “settled”.
• If you take a scatter-shot approach to proposals, it’s going to show. Folks who submit for one or two related topics generally tend to be talking about things they’re clearly experts in, and it shows in the proposals. There’s nothing more frustrating than seeing a half-dozen proposals from someone on a wide range of topics, none of which their proposals would lead you to believe they have specific or unique knowledge of. It’s painful because the proposals themselves are often of low quality, and frustrating because the topics tend to be important. Be focused, have something important to say on a worthwhile topic, and sell the topic (not just yourself). If you can do all of those things well for 6 or 7 proposals….well, you’re a better person than I.

In some sense, I hope that the truly bogus corporate-drone-submitted proposals don’t get much better. They’re easy to spot now, and their horrible quality makes them simple to filter out. Instead, I hope that folks who might otherwise be on the line find this list useful as a way to push them over the threshold.

My personal thanks go out to everyone who reads this blog and submitted talks this year. The quality in the web track is great, and many important topics are represented in the submissions that reflect how important the web is to Open Source (and vice versa).

In the past couple of years the shift from desktop-centric to a more web-centric OSCON has continued to make the conference useful and engaging, and great work on topics like JavaScript/Ajax performance, Dojo, Comet, and many of the emerging back-end bits of infrastructure that make it all go have made my yearly trip to Portland worthwhile.

Great talks have gotten lost from the JavaScript/web track in years past because they’ve missed the submission deadline, so if you’re hacking on something fascinating, now’s the time to get that proposal in. Make sure you flag it with the right track when you submit (javascript, ajax, web, or whatever they’re calling it this year), and don’t hesitate to ping me if you’re unsure about whether or not your talk got slotted correctly for the review process.