|
Size: 19968
Comment: Write some text
|
Size: 11771
Comment: Add more text
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | Line 8: |
| :Date: $Date: 2007-03-28 16:13:05 -0400 (Wed, 28 Mar 2007) $ | :Date: $Date: 2007-03-28 22:20:51 -0400 (Wed, 28 Mar 2007) $ |
| Line 21: | Line 21: |
| Line 115: | Line 114: |
| 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. |
|
| Line 119: | Line 157: |
| The critical things you need for a technical conference are: | The most important things about the location are: |
| Line 123: | Line 161: |
| #) Wireless Internet access for all attendees. |
|
| Line 127: | Line 163: |
| #) Optionally, food. XXX Name tags. We are open to multi-year bids, but you're certainly not forced to assume hosting the conference for two or more years. Multi-year contracts with hotels or conference centers can strengthen your negotiating position with the hotel and let you lower costs by extracting concessions. On the other hand, if there are problems with the hotel at the first conference, you're committed to using the location again and you don't have much negotiating leverage at that point. If you have any questions, suggestions, or would like to propose to host PyCon, write to the organizers' mailing list at <pycon-organizers at python.org>. You may want to assemble a set of web or wiki pages containing the information below. |
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. |
| Line 154: | Line 243: |
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. |
|
| Line 158: | Line 289: |
| Finances ----------------- XXX insurance? |
|
| Line 165: | Line 303: |
Formal Bid =========== We need a formal bid, including the following: * A description of the venue and conference dates. * A budget or summary of major costs (room rates, meeting space rates, food, network, A/V). Don't worry if you don't have every detail; just indicate what's missing. Include rate sheets * A hotel contract (possiblly after the venue decision) or a hotel proposal. For an example, see `the 2006/7 bid from the Dallas Fort Worth Pythoneers <https://dfwpython.org/DfwPyConBid/HomePage>`__. Decision Process & Timeline =========================== Bids should be prepared in time for PyCon 2007. Ideally we'd like to make a decision for 2008 by or at PyCon 2007. If we have one or more bids by PyCon, we can decide there, and we can sign contracts soon thereafter. If we can get bids in **before** PyCon, so much the better. Be sure to keep the conference committee informed (pycon at python dot org). The `Conference Committee`_ will make a recommendation on the bids to the PSF Board of Directors, who will make the final decision. .. _Conference Committee: PythonSoftwareFoundationCommittees#python-conference-committee-pcc General Requirements ==================== Conference Scheduling --------------------- Ideally PyCon would be held between mid-February and mid-April. The first three PyCons were held in Washington DC in late March; 2006/2007 were held from late February to early March. We have to watch out for Easter though; one PyCon ended up conflicting. PyCon has traditionally been in the late winter / early spring, EuroPython takes place in early July, OSCON is in late July, and SciPy is in August/September. We don't want the main Python events to be too close together. But we are flexible, and anything is possible. In 2006 & 2007, the main conference was held over a weekend (Friday-Sunday), with a tutorial day the Thursday before and 4 sprint days after (Monday-Thursday). Previously, the main conference was on weekdays (Wednesday-Friday), with 2 or 4 days of sprints before. Weekend or weekdays, both patterns worked. Sprints *after* the conference seemed to work out better though, as they start off with the most people and taper off, and it is worth noting that post-conference sprints allow for organization/evangelism during the conference. Tutorials before the conference make sense, but could also be held on the day after the main conference in parallel with sprints. Finances ------------ The PSF doesn't need to make an enormous profit, and can tolerate a small loss, but it's obviously better if the conference can be slightly profitable. The acceptable upper bound on the early-bird registration cost is $250, although we'd like to keep it closer to (or below) $200. As a first approximation you can assume that **everyone** registers at the early-bird rate. The PSF will sign the contracts and pay the bills. This means the PSF is legally liable and no insurance need be provided by the local organizers. Hotel or Conference Hall? ------------------------- Holding PyCon at a hotel with sufficient conference space is convenient: for most attendees, the weather won't be a factor, and there's no commute. A conference hall can work too; the first three PyCons were held at a university's conference center. Hotel Room Rates ---------------- If the conference is held at a hotel, we will be expected to fill a bank of rooms (see `Room-Night Obligation`_ below). The room rate should be as low as possible. In 2006/2007, the conference hotel room rate was $79 (+ tax == $90) for a single/double-occupancy room, which was quite reasonable. If the room rate is much higher, many people will be forced to look for cheaper accommodations elsewhere, and this may hurt the conference itself. It seems that it is standard practice for hotels to give a sales commission (10%) on the room rate to the organizing group. In effect, the hotel sees the organizing group as their sales agents. Be sure to ask for this commission. Look for terms like "non-commissioned rate" or "commissioned rate". If the conference does not take place at a hotel, there should be a range of accommodations nearby or accessible by public transit. Special attention should be paid to the low end: inexpensive hotels, motels, and hostels. Room-Night Obligation --------------------- A hotel with conference space may offer the space for free or at a reduced rate, with the understanding that the conference attendees will stay at that hotel. The conference will be asked to guarantee a certain number of room-nights. For PyCon 2006 & 2007, we contracted for 80% of 870 room-nights (696 room-nights). We totalled 955 room-nights in 2006 and 2007 will be well over our obligation. The distribution was approximately: * 80 room-nights for the night before the tutorial day, * 200 room-nights for each of the nights *before* the three conference days, * 100 room-nights for the night of the last conference day, * 50, 40, 30, and 10 room-nights for the following nights. There were a few rooms booked before and after these days. The 2006/2007 contract applied the conference rate up to 3 days before and after the event. The contract should apply the reduced room rate to all nights. The contract stated that *if* the hotel had *any* available rooms, even after the deadline, they must offer them at the conference rate. If you'd like more contract details, write to <pycon at python dot org>. Negotiate hard on any contract - the 2006/2007 contract with the hotel was highly customized. Venue Requirements ================== The bid must include rough cost information for all items below so that we can estimate the required registration price. Facilities ---------- **Auditorium**: A large lecture-hall style room that can hold all the conference attendees at one time (for keynotes). **Meeting rooms**: Three rooms with a total capacity approximately equal to that of the full assembly. One of these rooms may be the (possibly divided) auditorium. **Common area**: A common area in which groups of attendees can informally meet and where conference registration can take place. Requires a number (4 or so) tables for registration. **Sprint rooms**: two or more rooms for sprints. These rooms are usually re-used during the conference for open space talks. Multiple sprints can run at the same time, so these rooms should contain a number of tables that can seat ~10 people with their laptops. White boards for technical discussions are useful as well. **Quiet room**: A room for people to use their laptops in silence. This room should be able to seat 30-50 people at tables, and have an Internet connection. **Vendor & sponsor space**: Space in a high-visibility area (e.g., a hallway) for vendor & sponsor tables. **Storage**: A secure room in which to store supplies, including materials for all the attendees and all necessary equipment. All facilities 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.). It is important to keep the time required for attendees to move between rooms at a minimum. Therefore it is better if the rooms are located on one floor or that there be many elevators as well as stairs to handle the crowd movement. Networking ---------- Internet access is **extremely** important to PyCon. All areas of the conference (listed in Facilities_ above) need wireless and wired Internet access, for almost **all attendees simultaneously**. The venue may be able to provide the networking, or we may have to contract with a third party. In either case, service level guarantees and on-site support should be part of the agreement. Bandwidth: as much as possible. 2006 had 4 T1 lines, for a total of around 6mbps of bandwidth. We were using around 4mbps, so 4mbps is probably around the minimum we can live with. We are heavily inbound oriented, but probably need at least 2mbps outbound bandwidth. We need the ability to have quite a lot of associations with the wireless network. We're probably going to be one of the venue's heaviest per-attendee penetration of the wireless network. Comparing our 400-attendee usage to the vacuum salespeople's 400 attendee usage is not a fair comparison. Expect at least 200 (over 50%) simultaneous associations. **New:** For PyCon 2007, we are planning to purchase and deploy our own wireless networking equipment. The hotel is supplying jacks and bandwidth only. We expect to handle our own wireless from now on. Free Internet access (wired or wireless) in hotel rooms would be nice, but is not a requirement. Catering (optional) ------------------------ Catering is a major part of the cost of the conference. If catering is not provided, we should be able to arrange for outside catering, and it must be included in the overall cost. Provide: breakfast, snacks, and a light lunch for the three conference days. Some attendees will be vegetarian/vegan; some may require lactose-free or low-carbohydrate meals. While not all meals may be provided, the resources must be available. Snacks are less important than lunch; if no meals are provided at all, the resulting registration cost should reflect this. Breakfast is convenient but not obligatory. If food will not be provided, there should be restaurants or other places for lunch within walking distance. There should be enough of these to handle the conference attendance. If there's only one small restaurant within walking distance, it'll get swamped! Accommodation ---------------- Nearby commercial hotels, restaurants, and social venues must be available. If the facility is a hotel: how many rooms does it have? What would the room rate be? If the facility does not offer accommodation, some nearby inexpensive accommodations, such as hostels, should be identified. A/V Equipment |
To be mentioned |
| Line 417: | Line 306: |
| **Auditorium and Meeting Rooms**: Public address system, and data video projectors are required; transparency (overhead) projectors may be useful. Preferably wireless microphones as well as podium mics. Transportation ------------------- Nearby access to an airport, preferably a large one. Parking facilities or arrangements, as appropriate. How to arrive by public transport and taxi from the airport, or other major points. Volunteers ================== Some parts of PyCon organization can be done remotely, but having local volunteers is vital to the conference's success. Volunteers can: * Explore locations before the conference. * Receive deliveries in the weeks before the conference. * Run the registration desk. * Help advertise the conference locally at schools, user groups. * Help prepare the conference rooms, wireless networking, badges, conference tote bags, etc. Does your location have a pool of volunteer labour? Lessons Learned ================= The Chicago group helped to determine two things: 1. One year is not enough time to get our choice of venue & dates. We need to start deciding the venue *two* years in advance. I see two choices: take the next venue for two years, or decide the 2009 venue ASAP (deadline 6 months). Either way, we should be deciding the 2010 venue at PyCon 2008. 2. Few if any of us are experienced in selecting & negotiating with venues, and the experience we gain does not transfer to the next venue. Doing the venue selection & negotiation separately is counterproductive and stressful for all. The Chicago group has two recommendations: * A professional meeting planner may be invaluable to the initial venue selection & negotiation process. The Chicago group has had the benefit of a planner's advice and assistance. If it's a financial and organizational net gain for PyCon, we should retain the services of a professional meeting planner. The Chicago bid's budget may contain an entry for a meeting planner. * Rather than ask for bids from independent local groups, we should establish a permanent site selection committee that coordinates the effort. Ideas for sites would still come from local groups, but they wouldn't have to work so hard, and the PyCon organizers would be kept in the loop. This would be most effective if combined with the meeting planner. ----------------------- Alvin Wang's approach in the San Francisco bay area (edited): I talked to the Tourism and Convention Bureaus. There is usually one in each city/county. I ignored San Francisco and San Jose because they would not be interested in a conference that is so small. I contacted the 2 counties between the 2 big cities, Santa Clara and San Mateo. I went to each website and sent them email. Each one replied with a standard conference info form which I filled out. After that, each Bureau sent it to the hotels. Each County has over 100 hotels with meeting facilities. The hotels would then contact me with a preliminary bid. Since I was fairly specific, there were not that many respondents, which was good. I read over the bids and sent back further questions. I have met with one and I will meet with another next week. The Bureaus provide some extra conference planning assistance for free. They are paid by the hotels. Acknowledgements ==================== Portions of this document are derived from the `Perl Foundation's venue requirements <https://www.yapc.org/venue-reqs.txt>`__. |
Name tags. |
Planning a Python Conference
| Author: | Andrew M. Kuchling |
|---|---|
| Date: | 2007-03-28 |
Contents
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.
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.
Finances
XXX insurance?
References
BarCamp, PyCon-related materials, organizing sprints, open space planning.
To be mentioned
Name tags.