this is a german Web-Mirror of PYTHON.ORG powered by Domainunion AG

Planning a Python Conference

Author: Andrew M. Kuchling
Date: 2008-07-29

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 and energized.

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 only 20-50 attendees, the advice here will still be useful to you because the problems are much the same.

Larger conferences such as PyCon or EuroPython are more complicated to plan for many 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 conferences mailing 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, who 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 an absolute necessity for sprints. People will be writing code, and today writing code requires access to code 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 critical to have a skilled developer from the project who can actually answer questions from new developers and 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 end up with a room full of people staring at each other in silence? This is unlikely to happen in practice. In a sizable group, there will be some people who want to learn about something and other people who can talk about it.

Unconferences often feature lightning talk sessions containing 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.

Another benefit of putting sprints after the conference is making the sprint more efficient if you're having several days of sprints. The opening hours of a sprint are usually spent getting all the participants ready to work; they need to download software, check out a source tree, and figure out how to compile it. When sprints are before the conference, a new bunch of people arrive every day and need to perform the initial setup. A post-conference sprint starts out with the maximum number of attendees and people drop out as the days pass, 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. Volunteers 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.

During the months before the conference, schedule a regular volunteer meeting to discuss recent progress and what tasks need to be done next. Following a definite schedule pushes people to complete tasks in time for the next meeting. Meetings can be held in-person or over instant messaging or IRC. For PyCon, we met every two weeks for an hour, and two months before the conference the frequency increased to weekly meetings.

Finding a location

The most important things about the location are:

  1. One or more places to talk such as an auditorium or conference room.
  2. 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.

Your local Parks and Recreation Department may have art centers or community facilities that can be rented for a few hundred or thousand dollars.

Hotels are less practical for small conferences 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 mingle.

Storage: A secure room in which to keep supplies, such as electronic equipment and programs and other publications for the attendees.

Audio-visual equipment: A public address system and a video projector 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.

Networking: External access to the public Internet

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 have to use up 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, Yom Kippur, and Memorial Day, move around from year to year, so be sure to check the calendar when picking a date.

Drawing up the program

There are several different approaches to assembling a conference program.

Many conferences, such as PyCon, will post a Call for Proposals and wait for people to apply to give talks. The resulting mix of talks will therefore depend on the quality of the proposals received. If one field is underrepresented in the proposals, the resulting conference program won't cover that field very well.

Past EuroPython conferences have started with the organizers deciding on a set of topics: scientific programming, web applications, beginner tutorials, etc. For each chosen topic, a topic chair chooses a set of talks. How the talks are chosen is up to the chair; s/he may post an open call or invite specific people who've worked in the application area. Inviting people can be very effective: people are often shy and think "No one would want to listen to a talk from me", but will enthusiastically respond to an invitation.

If you're running an unconference, there isn't much to do before the conference; you simply have to trust that the attendees will have things to present and to talk about.

Every year PyCon surveys its attendees for what topics they'd like to see at future PyCons. The results for PyCon 2004, 2006, and 2007 are in the Python wiki and are a good source of ideas.

Don't over-schedule; you don't need to fill every single block of time with an activity. PyCon attendees usually report that the socializing during breaks, lunchtimes, and evenings is also a valuable part of the conference.

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 be assuming 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; plan accordingly.

Some facilities may have an existing wireless network. You should plan on bringing your own networking equipment to supplement it. If nothing else, try to get access to the facility's wired network and hang switches off that to minimize wireless congestion -- then encourage attendees to use the wired network.

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. Food needs to be stored and served carefully for health (and legal!) reasons. 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. Before the conference, you can explore the surrounding area and draw up a list of restaurants. Restaurant maps may also be available from your local chamber of commerce.
  • 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. Some areas have food delivery services that obtain food from regular restaurants.

OTOH, sponsoring catered food is an excellent way of attracting financial assistance (e.g. "This lunch is provided by XYZ Corp.").

Publicizing your conference

Publicizing your conference is important for attracting people who don't attend regular user group meetings or aren't aware of them. You can reach out to people who don't see themselves primarily as Python users, but as programmers or sysadmins or researchers who happen to use Python.

In 2007, online channels such as weblogs, web sites, and mailing lists are the most important way to publicize your conference, especially to the computer-using audience that would come to a Python event. There are certainly Python users who don't read python.org or comp.lang.python; try to reach them!

First of all, have a web site or at least a web page for your event. At a minimum the web page should include:

  • Dates for the event. (Include the year, in case no one takes the site down after the event is over.)
  • Directions to the location.
  • Program information such as a list of the presentations and short biographies of the presenters. If you can get the presenters to also post their slides before the conference, that will be very helpful to attendees.
  • An e-mail address for contacting the organizers.

Having a wiki is convenient; it lets presenters and attendees assemble their own information. You don't need to set up and administer your own wiki. Instead you can use the Python wiki at https://wiki.python.domainunion.de/moin/ ; create a page for your event and let attendees create new sub-pages as they wish.

Keeping a conference weblog will increase your visibility. A continual flow of announcements keeps your conference in people's minds and increases their excitement. Many free weblog hosting services such as Blogger are available, so it's very easy to set up a weblog for your event. Send a note to the python.org webmaster and get your weblog added to Planet Python.

Post announcements to relevant mailing lists. The python-announce list is the classic place for Python-related announcements, but also consider posting to specific lists; if you have a lot of database talks, post to the Database-SIG, for example.

Post to the announcement lists of other user groups in your area, too. Java user groups may be interested in Jython, web developer groups will want to hear about Django, and a polite note can be posted to local Perl or Ruby groups, etc.

Once the dates of the conference have been confirmed, add your event to various online event calendars. Doing so is usually free. Here are a bunch of calendars; doubtless there are more sites out there.

Write a formal press release and e-mail it to people. Getting your press release distributed by a commercial press service will cost a few hundred dollars and probably isn't worth the expense. Instead you can track down addresses one-by-one and e-mail people directly:

Less formally, you can write a one- or two-paragraph note about your event and e-mail it to computer science departments at your local schools. If you have contacts inside the school, ask them to post an announcement on the departmental bulletin board.

If a reporter is interested in attending, don't just leave him/her to their own devices. Help arrange interviews with speakers or attendees who will interest them: speakers with an interesting project, staff from a local company, etc.

Running your conference

It's hard to offer detailed advice on what needs to be done while an event is going on. This section is therefore rather scattered, a collection of tips and suggestions about various topics.

Often you'll have to react to problems such as the wireless network failing, a projector bulb burning out, or being unable to find a speaker who's supposed to start in 15 minutes. Before the event, consider various scenarios: what if a speaker doesn't show up? What if there aren't enough people to run an activity? Think about what you would do for each contingency -- start events scheduled later, or leave that block of time empty for private conversation?

One key to keeping yourself from going insane during the event is to prioritize. First solve large problems that affect many attendees; small problems can be fixed later, or simply not fixed at all.

Keep track of expensive pieces of equipment such as borrowed projectors and laptops. Most event venues have a lot of foot traffic from people passing through, and no one will notice a thief picking up a laptop and walking away with it. You can buy cable locks to tie equipment to a table. In the evening, be sure that all the equipment is collected and stored in a safe location that can be securely locked.

Have name badges for all your attendees and speakers. Conversations often start when attendee #1 notices attendee's #2 badge and says "Hey, you're the person who wrote XYZ! I use that module all the time." If printing name tags is too difficult to coordinate, you can just give the attendees blank labels and a marker. Badges can also list the attendee's employer or organization and their home town. Some conventions use ribbons or coloured dots to indicate fields of interest: say, green for science; blue for web applications; purple for game developers.

Make the conference staff visible so that attendees know who they can ask for help or report problems to. Staff can wear T-shirts in identical colors or have special badges.

Finances

There will certainly be some expenses required to hold an event. You can cover these expenses in several ways:

  • If the expenses are small, you may want to just pay the costs out of your own pocket, or divide the costs among the organizers.
  • Find companies or organizations that will sponsor the event in return for some advertising or a 'Sponsored by' credit.
  • Charge an admission fee. You'll need to get a cashbox to store the money received. Be sure to deposit the cash in the afternoon or find a safe to store it in; the money is a target for sneak thieves or an armed robber.
  • Ask the PSF (Python Software Foundation) for money. You will need to write a proposal that specifies how much money you want and what the money will be used for. Send the proposal to psf@python.org

Ask the venue whether the attendees for your event will be covered by their insurance. If someone's laptop is stolen or a person falls off the stage and is injured, will the organizers be responsible or will the expenses and possible legal fees be covered?

References

https://www.barcamp.org:
The world-wide site for Bar Camps.
https://www.ecoop.org/resources/HowTo.pdf
"How to organize ECOOP conferences", a conference guide for one specific academic event.
https://www.infrae.com/about/activities/sprintathon/tips
Tips for organizing a sprint.
https://www.onlamp.com/pub/a/python/2006/10/19/running-a-sprint.html
Another article on organizing sprints.
https://www.unconference.net/
A weblog about unconferences and how to run them.
https://frazzleddad.blogspot.com/2009/09/running-event-on-cheap.html
Weblog post: Running an Event on the Cheap

The PyCon organizers try to make their planning process as transparent as possible, and the resulting online resources may be helpful:

https://wiki.python.domainunion.de/moin/ConventionHowto
A checklist of necessary tasks. This list may remind you of items that have been forgotten or spark some ideas for your own conference.
https://us.pycon.org/TX2007/Planning:
The 2006/2007 PyCon web site was wiki-based, and there are lots of pages that were used for internal planning purposes. This page links to most of the planning-related pages for those years.
https://wiki.python.domainunion.de/moin/PyConPlanning:
More general pages on PyCon planning are linked from this page.

AdvocacyWritingTasks/RunningAConference (last edited 2009-10-06 12:43:25 by AndrewKuchling)

Unable to edit the page? See the FrontPage for instructions.