Differences between revisions 5 and 6

Planning a Python Conference

Author:	Andrew M. Kuchling
Date:	2007-03-28

Contents

Introduction
Types of conferences
Volunteers
Finding a location
Scheduling the conference
Drawing up the program
Networking
Food and Catering
Publicizing your conference
Finances
References
To be mentioned

Introduction

A great way to energize the Python community in your area is to hold a Python conference. Conferences are an excellent way for people to meet old friends and make new friends, to exchange ideas and knowledge, and to work together on projects using fast face-to-face discussions instead of slower e-mail and chat sessions. After a successful conference, people come away excited

In this white paper, I will be discussing how to organize and run a small conference, one that runs for one or two days and will have 50-100 attendees. If you want to run a smaller conference for 20 or 30 attendees, the advice here will still be useful to you because the problems are the same.

Larger conferences such as PyCon or EuroPython are more complicated to plan for several reasons. They run for three to five days, so you need to fill more program space. They'll usually attract a few hundred attendees, so your choice of locations is reduced and the likelihood of getting the location for free is small (schools are probably the only chance). Some of the information below will still be helpful, but if you're interested in planning such a conference, I suggest joining the pycon-organizers list and asking for advice. I'd also strongly suggest getting your feet wet by running a smaller conference first.

Types of conferences

Small conferences can be structured in a number of ways.

Planned conferences

A planned conference is the most traditional kind, with a fixed timetable and pre-selected schedule of speakers. Attendees will spend most of the conference time listening to speakers and occasionally making a comment or asking a question.

Pre-conference planning:

Speakers need to be chosen. The conference organizers might issue a call for speakers and then have a program committee select from the responses, or might invite specific people to give a talk.
The selected speakers then need to be arranged into a schedule for each day of the event.

Sprints

Sprints (also called hackathons) feature small groups of 3-10 people gather around a table and work on various projects. Sprints are very decentralized because there are no speakers who stand up and talk while the rest of the room listens; instead the activity is in the conversations within each small group.

Requirements:

Networking of some sort is a necessity for sprints. People will be writing code, and today writing code requires access to CVS/SVN repositories, bug trackers, and online reference materials.

Pre-conference planning:

Find out which projects will be present. A project needs a certain number of people in order to sustain a sprint. It may be necessary to have a skilled developer from the project who can actually answer questions from new developers, commit changes to the master repository.

Unconferences

An unconference is a conference where the content of the sessions is invented day-by-day by the participants. Often the program for each day is planned at the first session every morning. Participants introduce themselves, describe session topics they're interested in, and assemble into groups.

This may seem like a risky way to run a conference: what if no one suggests anything and you have a room full of people staring at each other in silence? In practice this is unlikely to happen. In a sizable group, there will be some people who want to learn about something and other people who can talk about it.

Conferences often feature lightning talk sessions consisting of a series of brief 5 to 10-minute talks, with a minute or two for questions between each talk. Many people can give such a short talk about a personal project or a library they've used, and writing three or four slides doesn't take much effort. Attendees enjoy lightning talks, too, because a single hour-long session will introduce them to ten or twelve different projects.

Alternate terms for unconferences are "open space conference" or "barcamp".

Combinations

You can combine more than one of these styles. For example, a two-day conference might feature one day of planned talks and one day for a more loosely-structured unconference or for sprints.

From my experience with PyCon, sprints are more efficiently held at the tail-end of a conference. Holding sprints after the conference talks means that sprints won't collide with any necessary set-up work, and lets speakers advertise their sprint and attract more participants. This is even more important if you're having several days of sprints, because the opening hours of a sprint are usually spent getting all the participants ready to work; they may need to download software, check out a source tree, and figure out how to compile it. A post-conference sprint starts out with the maximum number of attendees, so you can get this initial configuration completed for everyone.

Volunteers

It would be difficult (though not impossible) for a single person to organize and run a conference, but the job is much easier for a group of organizers. Different people can:

Explore locations before the conference.
Run the registration desk.
Help advertise the conference locally at schools, user groups.
Help prepare the conference rooms, wireless networking, badges, etc.

Your very first step should be to look for a pool of volunteers. Many conferences are organized by members of the local Python user group. If the conference location will be a school, there might be a computer club or ACM student chapter that can help with planning and running the event.

Finding a location

The most important things about the location are:

One or more places to talk such as an auditorium or conference room.
Equipment to talk with (a projector and screen, microphones).

Schools, libraries, hotels, and conference centers are all possible locations that might have rooms of the right size. As the number of attendees increases, locations get harder to find. In the US, most high schools, universities, or libraries will have an auditorium that can seat at least 100 people, and they'll also have classrooms that can hold 20-30 people.

Schools, libraries, or a Python-friendly company are your best bets for a relatively small conference because they may let you use the meeting space for free. Hotels are less practical because they'll either charge you for using their meeting space or expect you to attract enough guests to fill a block of rooms. In either case, you're making more of a financial commitment and may end up losing money.

The local Tourism and Convention Bureau for your city or county can probably provide a list of possible locations. This list may concentrate more on commercial locations such as hotels, but it can still be a good starting point.

If you're holding a multi-day conference or expect people will be traveling some distance, there should be a range of accommodations nearby or accessible through public transit. Special attention should be paid to inexpensive places to stay: motels, hostels, and low-end hotels.

Useful facilities at a location may include:

Auditorium: A large lecture-hall style room that can hold all the projected attendees (for keynote talks and an unconference's initial planning session).

Meeting rooms: Smaller rooms that can only hold a fraction of the attendees. Useful if the program is broken up into different tracks, or for sprints.

Common area: A common area in which groups of attendees can informally meet.

Storage: A secure room in which to store supplies, including materials for all the attendees and all necessary equipment.

Audio-visual equpment: A public address system and video projectors are required; transparency (overhead) projectors may be useful, especially for lightning talks. It's good to have both wireless microphones as well as podium microphones.

All locations should be accessible by disabled persons, and held in controlled temperature environments (air-conditioned or heated as needed).

The location should be accessible by public transport. It's a bonus if there are interesting attractions nearby (museums, attractions, etc.). Small conferences probably won't provide food, so there should be some restaurants or other dining facilities nearby for lunch, and enough of them to handle the conference attendance. If there's only one small restaurant within walking distance, it'll get swamped.

Scheduling the conference

Weekends are probably best for a small conference. Most attendees probably won't be sent by their employers and would therefore use up some vacation time if the conference is held during the work-week.

Think carefully before scheduling your conference for a holiday. While it might be appealing to use a long weekend such as Thanksgiving, people often schedule family events for holiday weekends and will be reluctant to spend a day at a conference. Some holidays, such as Easter and Memorial Day, move around from year to year, so be sure to check the calendar when picking a date.

Drawing up the program

Event ideas: talks, sprints, lightning talks.

Finding papers.

Networking

Internet access is extremely important for a technical conference. Many people will have laptops, and attendees like to download the software being presented or look at related web sites.

You should plan to have enough networking capacity for almost all attendees simultaneously. Some locations may optimistically claim to support your projected number of attendees, but may assume that only a small percentage of attendees will be using the network. For a Python-oriented audience, it's safer to assume that 90% of the attendees will be using the network and plan accordingly.

Food and Catering

Providing food is a major source of complications. Food is expensive, especially if the location requires you to use a particular catering service. You also need to worry about providing options for vegetarians or people with food allergies.

For a low-effort conference, I suggest not providing any food. Instead:

Choose a location where restaurants and stores are within walking distance.
Schedule a long-enough lunch break (90 minutes or two hours) so that people can visit a nearby restaurant.
Or, look for a location where there's a cafeteria that will be open.
Ask the location whether attendees can order pizza or other food and have it delivered. This works well for activities such as sprints where people are in small groups; a small group can quickly decide what to order and everyone can contribute $5 or $10.

Page

User