Differences between revisions 9 and 10
⇤ ← Revision 9 as of 2007-04-15 02:00:01 →
Size: 22226
Editor: AndrewKuchling
Comment: Add more text
← Revision 10 as of 2008-07-30 00:35:43 → ⇥
Size: 23267
Editor: dsl092-163-165
Comment:
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
:Date: $Date: 2007-04-14 20:57:41 -0400 (Sat, 14 Apr 2007) $ :Date: $Date: 2008-07-29 $
Line 24: Line 24:
and energized.
Line 72: Line 73:
Sprints (also called hackathons) feature small groups of 3-10 people Sprints (also called hackathons) feature small groups of 3-10 people, who
Line 80: Line 81:
* Networking of some sort is a necessity for sprints. People will be
  writing code, and today writing code requires access to CVS/SVN		 * Networking of some sort is an absolute necessity for sprints. People will be
  writing code, and today writing code requires access to code
Line 87: Line 88:
  number of people in order to sustain a sprint. It may be necessary   number of people in order to sustain a sprint. It may be critical
Line 89: Line 90:
  answer questions from new developers, commit changes to the master   answer questions from new developers and commit changes to the master
Line 103: Line 104:
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		 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
Line 108: Line 109:
Conferences often feature lightning talk sessions consisting of a
series of brief 5 to 10-minute talks, with a minute or two for		 Unconferences often feature lightning talk sessions containing
a series of brief 5 to 10-minute talks, with a minute or two for
Line 130: Line 131:
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		 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
Line 134: Line 137:
compile it. A post-conference sprint starts out with the maximum
number of attendees, so you can get this initial configuration		 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
Line 144: Line 149:
of organizers. Different people can: of organizers. Volunteers can:
Line 154: Line 159:
computer club or ACM student chapter that can help with planning and
running the event. 		computer club or ACM student chapter.
Line 161: Line 165:
instant messaging. For PyCon, we met every two weeks for an hour, and instant messaging or IRC. For PyCon, we met every two weeks for an hour, and
Line 186: Line 190:
Local Parks and Recreation Departments often have art centers or Your local Parks and Recreation Department may have art centers or
Line 216: Line 220:
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		 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
Line 241: Line 245:
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.		 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.
Line 248: Line 252:
such as Easter and Memorial Day, move around from year to year, so be
sure to check the calendar when picking a date.		 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.  
Line 268: Line 272:
open call, or may invite specific people who've worked in the open call or invite specific people who've worked in the
Line 271: Line 275:
and will enthusiastically respond to an invitation. but will enthusiastically respond to an invitation.
Line 299: Line 303:
support your projected number of attendees, but may assume that only a support your projected number of attendees, but be assuming that only a
Line 302: Line 306:
attendees will be using the network and plan accordingly. attendees will be using the network; plan accordingly.
Line 309: Line 313:
service. You also need to worry about providing options for
vegetarians or people with food allergies. Food needs to be stored
and served carefully for health reasons.		 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.
Line 345: Line 349:
are probably Python users who don't read are certainly Python users who don't read python.org or comp.lang.python; try to reach them!
Line 363: Line 367:
their own information. If you don't want to set up and administer
your own wiki, use the Python wiki at http://wiki.python.org/moin/ ;		 their own information. You don't need to set up and administer
your own wiki. Instead you can use the Python wiki at http://wiki.python.org/moin/ ;
Line 370: Line 374:
increases their excitement. Many free weblog hosting services are
available, such as `Blogger <http://www.blogger.com>`__, so it's very		 increases their excitement. Many free weblog hosting services such as `Blogger <http://www.blogger.com>`__ are
available, so it's very
Line 380: Line 384:
post to the Database-SIG, for example. Post to the announcement lists
of other user groups in your area, too.		 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.
Line 402: Line 408:
You can write a formal press release and e-mail it to people. Getting
your press release picked up by a commercial press service will cost a		 Write a formal press release and e-mail it to people. Getting
your press release distributed by a commercial press service will cost a
Line 425: Line 431:
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.
Line 433: Line 442:
Often you'll find yourself reacting to problems such as the wireless
network failing, a projector bulb burns out, or a speaker who's
supposed to start in 15 minutes can't be found. Before the event,		 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,
Line 438: Line 448:
you would do -- start events scheduled later, or leave that block of
time empty for private conversation.		 you would do for each contingency -- start events scheduled later, or leave that block of
time empty for private conversation?
Line 443: Line 453:
small problems can be fixed later, or end up being ignored.

Pay attention to expensive pieces of equipment such as borrowed		 small problems can be fixed later, or simply not fixed at all.

Keep track of expensive pieces of equipment such as borrowed
Line 450: Line 460:
is collected up and stored in a safe location that can be securely is collected and stored in a safe location that can be securely
Line 453: Line 463:
You should have name badges for all your attendees and speakers. Have name badges for all your attendees and speakers.
Line 458: Line 468:
also list the attendee's employer or organization and their home town. 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.
Line 509: Line 522:
  of the planning-related pages.   of the planning-related pages for those years.
Line 512: Line 525:
  Planning pages for earlier PyCons are in the Python wiki.   More general pages on PyCon planning are linked from this page.

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 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, 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.

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.

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.

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 http://wiki.python.org/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 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

http://www.barcamp.org:
The world-wide site for Bar Camps.
http://www.infrae.com/about/activities/sprintathon/tips
Tips for organizing a sprint.
http://www.onlamp.com/pub/a/python/2006/10/19/running-a-sprint.html
Another article on organizing sprints.
http://www.unconference.net/
A weblog about unconferences and how to run them.

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

http://wiki.python.org/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.
http://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.
http://wiki.python.org/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.