I wanted to blog about my impressions as a program committee volunteer. Note that this is totally unofficial, and I'm not speaking on behalf of the committee, PyCon, etc.
It was wonderfulJust reviewing the talks was a great experience. Some of the talks were fun just to visualize; watching them will be even better. I learned lots about what is going on in the Python community. The program committee is a smart and fun crowd to work with, too.
It was horribleThe problem with a programming language that can do pretty much anything is that three days of scheduled talks are nowhere near enough to see everything that's going on. I wish we could have five days of talks, but there are too many people who wouldn't have the time or money for such a conference.
With room to accept fewer than half of our submissions, we had to turn away talks that would have been great. For instance, the one talk I most wanted to see - the proposal I would have walked barefoot to Atlanta for - got declined. What can you do? Often "pretty much everybody was pretty excited about this" talks had to be sacrificed for the sake of "virtually everybody was dying to see this" talks.
But wait, there's moreFortunately, scheduled talks are only the tip of the PyCon iceberg. We have Lightning Talks, Open Spaces, and (new this year) poster board sessions! I hope all declined speakers will consider taking their material to one or more of those formats!
PyCon is going to be wonderfulI think we have the best crop of presentations we've ever had. If you can look through the list of accepted talks and not start making Atlanta travel plans, then you are already dead.
PyCon is going to be horrible... because, with five simultaneous tracks packed with the very best of material, I promise you will face multiple can't-miss talks going on at the same time, all day, every day. The painful decisions of the program committee are really only a preview of the difficult decisions every attendee will have to make at the conference itself.
For 2011: increasing your chancesIf you want to make your future PyCon proposal more appealing to the committee (making our decisions even harder - thanks a lot), here are some of the things I saw that helped talks make the cut.
- The basics: a clear talk description, orderly-looking outline, plausible-looking timings. If reviewers ask questions, answer them. Give every impression that you're prepared to put serious effort into your talk.
- Broad appeal. It's OK to present on specialty topics, of course, but if you can point out ways that even people outside the specialty will also want to see it, it will help.
- Unusual topic. Every year, there are some hot topics that everybody in the community seems to be talking about... and submitting talks on. Since we're not going to accept a dozen talks on any topic, no matter how hot, these talks need to prevail over a lot of competitors. On the other hand, if you've got a topic that makes the committee say, "HUH? Wow, I'd never heard of anything like that!", it really helps you stand out.
- We always get more intermediate-level submissions than for beginner or advanced, so the competition was fiercest there.
- What will attendees get from your talk that they couldn't get simply from reading the docs? Make sure we can tell.
- Evidence of preparation and skill. Some speakers had established reputations as skillful, engaging presenters; some provided links to their slide decks from earlier versions of their talks given at local groups or regional conferences; a few linked to actual recordings of earlier versions of their talks. Give your talk at a nearby usergroup, then convince one of your group members to volunteer for the program committee. :)
- Scratch the itch. When committee members say, "Ah, yes, I've been puzzled by that and dying for a proper explanation!" - or, "I personally understand it, but I see misunderstanding of it throughout the community and wish somebody would help clear it up", that is a big plus.
- Keep the Py in PyCon. If the topic is one of general IT interest - database technology or rich web client programming, for instance - then make sure to emphasize the Python angle of your talk. How do you work the problem from Python specifically? What do Python users need to know about the problem that they won't learn from materials aimed at the IT community overall?