Infrequently Noted

For the last several years I've been lucky to serve on the OSCON program committee. What that means, basically, is that for a couple of weekends a year I sit down with all the talks that have come in through the "call for participation" process for my track (web stuff) and try to sort out good from bad.

Once that's done, we try to identify any holes in the program and fill them to ensure that OSCON really does benefit attendees and that speakers and talks represent the diversity in views and interests of the Open Source world. My personal perspective is that it's the Program Committee's job to zealously guard the quality of the talks since the PC doesn't represent that business side of OSCON, but rather the attendees. I've always been impressed with how hands-off ORA is about this part of the process, ensuring that everyone gets a fair shake (as far as the PC is concerned).

Part of that responsibility is to make sure that when you go you're not marketed to outside of the clearly labeled exhibitor booths. Content is content. Marketing is marketing. They both have a place, but that place is clearly marked and that's one of the ways that we try to keep OSCON good.

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).