brian d foy

About a week ago, the call for proposals for the Open Source Conference closed. It's a bit fuzzy because many people only realize what month (or year) it is only after the submission link disappears, so we let a few extra proposals slip in. Don't ask now: it's too late. For reals this time.

As part of the Perl Track committee, I just reviewed all of the proposals where the submitter marked it as a "Perl" talk. Several other people from the Perl track also reviewed them. There are going to be some very nice presentations this year, and at least one demonstration of highly advanced Perl technology that you'll want to see twice in a row, and maybe a third time at the end of the conference.

The Perl track can accept around 15 to 20 talks, roughly. In reality, there are about four fewer than that because there are two outstanding Australian speakers who could tell us they were going to read the phone book and they'd still get more people to show up than any other talk, and they each give two talks. You're competing for the remaining, non-Australian slots.

Part of the non-Australian slots go to invited talks, too. Part of the committee's job is to hunt down and nag people to submit interesting topics, and sometimes even help potential speakers develop topics that the conference thinks will attract people. Those people tend to have the inside scoop on hot topics that we want at the conference.

From there, the committee starts with the submissions with the highest rating average and make their first picks from that. There are plenty of submissions that got perfect scores. Many of these are known speakers with a proven, long-term history of packed rooms and excellent exit scores. Maybe a quarter of the talks will come from this group.

Not even all of the submissions that get perfect scores will make it in. We have to balance the topics, and we want to cover diverse topics. If too many talks, although excellent on their own, would unbalance the conference, some won't make it. We don't need 10 talks on exciting new advances in web frameworks.

Now, the rest of the submissions are competing for the remaining half of the slots and the reviewers have to figure out how to separate the worthy ones from the unworthy ones. Remember, the immediately attractive talks have already been selected. The rest are the not-immediately possibly attractive talks.

Here's a short list of reasons why you might not get that acceptance email, and things to think about before you submit proposals to other conferences (or try again at OSCON 2011). Since we don't give individual feedback, you have to examine your own proposal to see if any of these apply. If you feel guilty that some did

• The more categories you give your talk ('Databases', 'Tools & Techniques', 'Perl', 'Emerging Topics', 'Linux-enabled Jello Molds'), the more reviewers you attract. Each reviewer is thinking about the number of slots available in their track, so if you're trying to muscle into a category where you don't belong, those reviewers will rank you lower. You won't make it into the cream that got acceptances on the first pass. Figure out which two categories you would most want to be in and no more.

• You want to be in the Perl track, and you think that since you used Perl for part of the project that it's instantly interesting to Perl people. It's not. People want to learn something about Perl that they can use in their own work. If you aren't going to teach them something about Perl as one of the major parts of your talk, you need to find a different track.

• From your description, we can't tell what the audience will get from your talk. You probably hate marketing-speak as much as anyone else, but you didn't recognize it in your own submission. If your description sounds like you are recruiting users for your product or program, you probably didn't get the higher votes that could have helped you.

• You assumed that we already know about your project, or that we know all the new things that have happened to your project since we stopped paying attention to it three years ago. Maybe it has had the most exciting and groundbreaking advances with resurgences of new users and you're about to go public and buy Google. If the handful of extremely busy reviewers don't read about that in the proposal, it's not going to be part of their vote.

• Additionally, you might be the king of your section of the open source world, but you were too modest in your submission to tell us about yourself. Really, we don't know everyone, so don't assume that the unnamed group of people who decide your OSCON fate know who you are. In reality, everyone on all committees get to vote on all talks, so there's a good chance most of the potential reviewers don't know who you are. If they did, you were probably already accepted as a speaker.

• You're doing the same talk year after year. You're talk might be good, but we can't keep showing the same talks every year. There's a limited number of slots, and all other things being equal, if it's your old talk and someone's equally good new talk, it's turns out to be a little less equal and not in your favor. Don't become complacent. You don't get bonus points for giving a talk at last year's OSCON.

• It's an open source conference. If you're talking about something you can't show, well, it's not that open is it?

• Or, finally, you just had bad luck. There might have been nothing wrong with your talk, but in the end we can only accept so many, have to work out various scheduling problems, or the stars just do not align. The committee doesn't have the final say on anything, so maybe we liked your talk and something else bumped it. Sometimes life sucks.