Differences between revisions 6 and 7
Revision 6 as of 2007-03-29 18:39:34
Size: 11771
Comment: Add more text
Revision 7 as of 2007-03-30 19:32:30
Size: 16755
Comment: Add more content
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Line 8: Line 9:
:Date: $Date: 2007-03-28 22:20:51 -0400 (Wed, 28 Mar 2007) $ :Date: $Date: 2007-03-30 15:09:56 -0400 (Fri, 30 Mar 2007) $
Line 24: Line 25:
50-100 attendees. If you want to run a smaller conference for 20 or
3
0 attendees, the advice here will still be useful to you because the
problems are the same.  
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.
Line 29: Line 32:
plan for several reasons. They run for three to five days, so you plan for many reasons. They run for three to five days, so you
Line 239: Line 242:
XXX
Line 242: Line 247:

Point to PyCon feedback for ideas
Line 288: Line 295:
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 probably Python users who don't read

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. If you don't want to set up and administer
your own wiki, use the Python wiki at http://wiki.python.org/moin/ ;
create a page for your event and let attendees create new pages as
they wish.

Keeping a conference weblog will increase your visibility. A
continual flow of announcements will keep your conference in people's
minds and increase their excitement. Many free weblog hosting
services are available, such as `Blogger <http://www.blogger.com>`__,
so it's very easy to set up a weblog for your event.

Post announcements to relevant mailing lists.
The `python-announce list <http://mail.python.org/mailman/listinfo/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.

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.

   * http://wiki.python.org/moin/PythonEvents
   * http://www.linuxjournal.com/xstatic/community/events
   * http://lwn.net/Calendar/
   * http://campus.acm.org/public/calendar/
   * http://www.tsnn.com/
   * http://techvenue.com/
   * `The IEEE conference calendar at computer.org <http://www.computer.org/portal/site/ieeecs/menuitem.c5efb9b8ade9096b8a9ca0108bcd45f3/index.jsp?&pName=ieeecs_level1&path=ieeecs/conferences&file=calendar.xml&xsl=generic.xsl>`__
   * http://www.linux-magazine.com/Readers/Events
   * http://www.eventful.com
   * http://www.upcoming.org
   * http://www.linux.org/event/
   * http://www.devtownstation.com/ddj.asp
   * http://www2.cio.com/events/index.cfm
   * http://www.conferencealerts.com

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
few hundred dollars and probably isn't worth the expense. Instead
you can track down addresses one-by-one and e-mail people directly:

   * Dr. Dobbs Journal http://ddj.com/contact.html
   * Linux Journal : events page http://www.linuxjournal.com/xstatic/community/events
   * ACM Queue http://acmqueue.com/modules.php?name=Sections&op=showpage&pid=32&secid=10
   * http://www.linuxgazette.net
   * http://www.linuxgazette.com
   * http://techrepublic.com.com/
   * Baseline: http://www.baselinemag.com/article2/0,1540,64,00.asp
   * IEEE Computer: http://www.computer.org
   * Your local newspapers. Identify the paper's technology reporter
     and e-mail them. Don't expect a response; reporters get many
     press releases every day.
   * School or campus newspapers.

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.


Running your conference
-------------------------------

XXX name tags
Line 299: Line 399:

BarCamp, PyCon-related materials, organizing sprints, open space planning.


To be mentioned
-------------------

Name tags.
http://www.barcamp.org:
  The world-wide site for Bar Camps.

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. Exploring these pages
  may spark some ideas or remind you of things to do.

http://wiki.python.org/moin/PyConPlanning:
  Planning pages for earlier PyCons are in the Python wiki.

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.

Planning a Python Conference

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

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 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 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:

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

XXX

Event ideas: talks, sprints, lightning talks.

Finding papers.

Point to PyCon feedback for ideas

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.

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 probably Python users who don't read

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. If you don't want to set up and administer your own wiki, use the Python wiki at http://wiki.python.org/moin/ ; create a page for your event and let attendees create new pages as they wish.

Keeping a conference weblog will increase your visibility. A continual flow of announcements will keep your conference in people's minds and increase their excitement. Many free weblog hosting services are available, such as Blogger, so it's very easy to set up a weblog for your event.

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.

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.

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

Running your conference

XXX name tags

Finances

XXX insurance?

References

http://www.barcamp.org:
The world-wide site for Bar Camps.
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. Exploring these pages may spark some ideas or remind you of things to do.
http://wiki.python.org/moin/PyConPlanning:
Planning pages for earlier PyCons are in the Python wiki.
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.

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

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