On Conferences

Bruce Eckel was unhappy about some things that happened at PyCon and wrote about them. A lot of his concerns are relevant to conferences in general, so I decided to break this into another post. The PyCon one was getting long. The crux of his dissatisfaction was that he felt that sponsors had been given too much access to the conference content (keynotes and lightning talks) in exchange for their sponsorship. I agreed with this and I told Bruce that in person. Frank and I were given a sponsored lightning talk slot, which we used to try to explain our new jobs to the Python community. Having been to PyCon previously it was a bit uncomfortable to be there in a “priority scheduled” slot. No sane company would want to make a bad impression on the attendees of a conference, yet in aggregate, this is precisely what happened this year. Having also talked with some of the organizers during sprint week, I am pretty sure that this will never happen again.

Predictably, there has been a lot of commentary, in response to Bruce’s post. Lots of people are upset for various reasons. Attendees are unhappy for one reason or another, and organizers and volunteers feel that they have worked a thankless task only to be kicked in the teeth.

I am both happy, and unhappy. I love PyCon. I love it even more than ApacheCon, because it has managed to retain more of that volunteer spirit. While there was a production company involved, from what I was able to see, the volunteers are still doing most of the work. I think that this is incredibly important, because no production company can know a community as well as a diverse set of volunteers drawn from the community itself. Without that knowledge, it is very hard to do a good conference.

Even with intimate knowledge of a community things are still complicated. The Python community itself is diverse, and growing. That means that the community is going to have different segments in it. I would be willing to be that there were a lot of people who came to PyCon to kick the tires on Python and it’s associated technologies, or to learn something new after maybe a year or so of programming in Python. Those folks have very different needs from people like Bruce or me. Bruce isn’t really interested in an eyes forward conference, and neither am I for the most part (unless Armin Rigo is going to talk about abstract interpretation o r partial evaluation). But many folks coming to a new topic area are looking for stuff more like tutorials, and introductory talks, which tend to be eyes forward stuff.

The key here is for everyone to have enough choices, and to me, that means that a good conference (not just PyCon) will look something like this.

  • The Hallway track – this just happens
  • Open Spaces for long time community members and/or advanced/specialized topics – this needs modest resources but needs promotion so that people understand how important these are and how to use them. O’Reilly has run OSCamp alongside of OSCON for a few years now, but OSCON is always played up as the major thing. But in today’s day and age, I think those roles probably ought to be inverted.
  • Lightning Talks – I am sad to admit that I want to far too many conferences where I ignored the lightning talks – to my detriment. I think that we owe the Perl folks a rich debt for having come up with the idea. Educating people on the value of lightning talks is good. I’d like to see the lightning talks moved to a more prominent spot, say, earlier in the day. I also think it would be worth soliciting a few people to give a lightning talk.
  • Regular Talks – If you are giving a real/regular talk, then I expect a lot. If you start reading to me about your project, I will be unhappy, because I guarantee you that I can learn more about your open source project by reading your project website during your talk than by listening to you. If I can’t, then there are larger problems a foot. You need to really say something really interesting or unusual in order to give a talk.
  • Keynotes – keynotes either need to be expansive, of incredibly broad interest (like python-3000, which Guido himself said was getting boring to talk about, since it’s been the same talk the last 2-3 years), or very entertaining. Best example of very entertaining would be the end of OSCON keynotes by the guys from WETA digital featuring theretofore unseen footage from the Lord of the Rings movies
  • Tutorials – this is basically old hat, but the people that need them, really need them

Also, for PyCon, we need to keep up the tradition of code. I loved walking down those hallways at GWU and seeing people huddled in pairs over a laptop cranking stuff out. It was amazing this week to walk through the entire downstairs area and see all the sprint labels on the doors.

One other note on conferences. Twitter is it. As usual, there were some difficulties with the PyCon WiFi – first time in a hotel that has never hosted geeks before, so it was inevitable. For those of us not smart enough to bring an EVDO card and router, getting connectivity was tough. The reason I missed that the most was the Twitter backchannel. There was an official pycon twitter feed (a bot, I’d guess), but there was also the backchannel of friends. Here are some real life examples of Twitter in action at PyCon.

  • Bruce Eckel decided to host an open space on concurrency, a topic I am really interested in. The only way that I found out about it was that Dianne Marsh, twittered it to the pycon reflector. I managed to get there in time for some interesting discussion, and to see who else was interested in the topic.
  • During the sprints, Donovan Preston was tweeting things like
  • Compiled nginx with mod_wsgi, so far so good, now to test

    which ultimately goaded me into going down the hall to find out what he was up to.

The value in conferences is all being there together. There are plenty of different ways to structure that time together, each able to serve a different kind of audience. Why not have them all and give people a choice?

Leave a Reply

Your email address will not be published. Required fields are marked *