Conventions at Light Speed: What Hackers Can Learn From SF Fandom <author>by Eric S. Raymond <date>v1.0, 28 October 1998 <abstract> Science-fiction fans have developed an excellent toolkit of techniques for running effective conventions and shows on a shoestring budget with all-volunteer staff. This document lays out some of the techniques for the use of people running Linux and open-source gatherings. </abstract> <toc> <sect>Introduction <sect1> Purpose of this document By the time I went to my first Linux convention in May 1997, I had been going to science-fiction conventions for twenty years. I immediately noticed that the people who attend and organize Linux conventions are much like science-fiction fans; they have similar interests, strengths, and weaknesses. I also noticed that, by the standards of SF conventions, hacker-run gatherings are, well, primitive. SF fans have a continuous tradition of amateur-run conventions going back sixty years; in that time, they've forgotten more about how to run conventions than hackers have yet had time to learn. In this document, I try to adapt and summarize some of these techniques for the use of people running Linux and open-source gatherings. If you apply these, I guarantee you'll give the customers a better time and be less stressed-out from running things. <sect1>Versions of this document If you're looking at HTML through a Web browser, you can download <url url="sfshows.sgml" name="SGML source"> or <url url="sfshows.ps" name="Postscript"> here. This document will be updated as I think of things to add. (The hard part isn't writing them down, it's bringing to conscious attention things that I have soaked up through my pores over a period of many years.) <sect1>Feedback and corrections If you have questions or comments about this document, please feel free to mail Eric S. Raymond, at <htmlurl url="mailto:esr@thyrsus.com" name="esr@thyrsus.com">. I welcome any suggestions or criticisms. If you find a mistake in this document, please let me know so I can correct it in the next version. Thanks. <sect>Shaping the social space Programming may be what draws people to technical conventions, but the most important interactions are the spontaneous ones that happen because you've got a lot of people with similar interests bumping into each other. The more of these an attendee experiences, the richer his or her experience will be. The way to encourage these interactions is to create areas in the social space that people naturally gravitate to when they have nothing else to do. Here are two good techniques: <sect1>Have a traffic focus during the day If possible, try to arrange the physical layout of your convention space so there's one traffic area that people more or less need to pass through in order to move between program items, the show floor, and their hotel rooms. Ideally this area should have places to sit and snack food nearby. What you're trying to do is make a comfortable place to wait for events that tends to gather people and promote conversation. <sect1>Have a central hospitality suite at night The biggest single design mistake that people who run technical conventions make is failing to promote after-hours social interaction. If people just dissipate after dinnertime for lack of a place to find conversation, that's a sin and a waste. Any SF fan knows that the really worthwhile stuff at a convention happens between 9:00 PM and two or three in the morning. The way to fix this is to have what SF fans call a `con suite' -- a suite or public room open at least from just before the end of daily programming until early the following morning. At some SF conventions the con suite never closes. The con suite should feature lots of places to sit. It should have sodas and snack food, and perhaps beer. You'll need one or two people to run it, but this is light duty; it mainly consists of keeping the snack bowls filled and a bit of cleanup. <sect1>Sign, sign, everywhere a sign Informative signs are vastly more important than people usually realize. Your event won't work if the attendees and staff can't find things. It's also important to help attendees form a clear mental map of what's where which (among other things) tells them where the focal areas are. Each program room should have a sign listing its event times. Key locations like the con suite, convention ops room, and green room should be signposted. The registration desk should have a large sign nearby featuring a floorplan of the public areas. Key intersections in the hall pattern should have this-way/that-way signs pointing to nearby locations. Good signs reduce the hour-by-hour friction costs of running the event. This is so important that there should be one person on staff whose only pre-convention job is to worry about signage -- to walk through the space in advance locating and laying out signs, and then making sure they're printed and erected before the convention opens. <sect>Programming without bugs There are lots of things SF fans have learned about how to run convention programming smoothly. Here are some high points: <sect1>Recruit gofers To reduce the load on the convention staff, recruit gofers. Ask convention attendees to help work the convention. Have a signup sheet, and a gofer monitor who tracks the hours they work. Here are some uses for gofers: <itemize> <item>Show setup/teardown <item>Moving AV equipment <item>Running messages <item>Printing things <item>Purchasing runs for office supplies, food <item>Rounding up missing speakers <item>Manning the registration desk <item>Room monitor duty (see below) </itemize> Recruit gofers with a pitch in your program book. Also, announce the gofer program (and its rewards) in your web pages so you get gofer signups early. Reward them with one or more of the following: <itemize> <item>Partial refund of show admission, pro-rated to the number of hours they work. <item>Convention T-shirt. For style points, mark the shirt "Staff" or "Gofer" and make it unavailable to regular attendees. <item>Admission to the ``gofer hole'', a staging area with food and places to nap. </itemize> These perks can make gofer status a powerful lure for broke students. It's a win-win deal; they get a less expensive conference, the staff gets warm bodies to do gruntwork. In general, if the core staff has to do much besides making decisions and managing gofers, that means they're working too hard. <sect1>Room monitors and rovers Every program item needs a room monitor. The room monitor's job is to make sure AV equipment is in place, route last-minute requests from the speaker to the con staff, and give the speaker a high-sign five minutes before the time slot ends. Typically you want two monitors per program track, alternating. While one is in the room assisting a speaker, the other is waiting in the green room for the next speaker. You also need rovers. A rover is a troubleshooter not assigned to a specific area. Room monitors can be gofers, but rovers should be core staff with decision-making authority. Give them radios with a link to the convention operations room. <sect1>Have a `green room' At SF conventions it's traditional to have a `green room' which is a staging area for speakers (the term is borrowed from show business, in which the green room is where actors wait for their turn on stage). The green room should have water, snacks, places to sit. But it's more than a perk for speakers; it's also a way to keep control of them. Your speakers should be urged to check in at the green room ten or fifteen minutes before their talk. There they can be met by their room monitor and escorted to their talk venue. If you run your green room and your room monitors properly, you'll find you can avoid the accumulating schedule slippage that's otherwise common at technical conventions. That never happens at SF conventions. <sect1>Use badge ribbons Another un-obvious friction cost is the time cost of finding people whose faces you don't know. Often (for the staff) these are people in special categories like core staff, gofers, speakers, press people, and vendor reps. SF fans address this problem with badge ribbons -- one color for core staff, another for gofers, another for press, etc. This makes it much easier to scan a room and quickly locate (for example) the core staff members. <sect1>Show up a day early Plan for last-minute panics. It always happens, no matter how hard you plan for other things. To cope, show up a day early. Total up all the hours you think are needed for setup, then give yourselves the extra day. If you do this, you'll actually have time to print programs, put up signs, and do all the other little things that you grossly underestimated the necessary time for. You'll also get a good night's sleep before the show opening -- that's important. <sect>Peer-to-peer communications Finding people whose faces you don't know is also a problem for attendees. Here are a couple of techniques for addressing this and supporting other kinds of peer-to-peer communications: <sect1>Have a voodoo board A `voodoo board' is a message drop for attendees. It's a big cork board covered by a printout of all the pre-registered attendees' names, with a checkbox next to each. Next to the board, place a little table bearing a box of push-pins, an index-card-sized filebox with alphabet dividers, a couple of ballpoint pens, and a bunch of small memo pads. Instructions posted above the board should explain how to use it. When an attendee arrives, he/she should put a check next to his/her name. To leave a message, write it on the memo pad and file it in the box under the initial of the recipient's last name. Then put a push-pin next to the name. To check for messages, just look for a push-pin next to your name. If there is one, retrieve your memo and remove the push-pin. This setup may be low-tech but it works really well. Ideally, it should be placed just off the daytime focal area of the convention. One of the things it does is prevent the rest of your message boards from getting clogged with person-to-person notices. <sect1>Have a grafitti wall. Cover a large section of wall with butcher paper. Have felt-tip pens nearby. Mark the top ``GRAFITTI WALL'' in huge bloob letters. Seed it with a few jokes and a cartoon. Stand back... <sect1>Recognition dots This is a fun hack I saw at Linux Expo '98 that I'm going to import back to SF fandom. Recognition dots are signals about your interests that you can attach to your convention badge. Have an easel or section of wall, again covered with butcher paper, marked ``RECOGNITION DOTS -- MAKE UP YOUR OWN''. Nearby, have a table bearing few packets of multicolored gummed-paper dots (all stationery stores carry these), a several felt-tip pens (again in multiple colors), and a scissors. Seed the display with a few pre-designed recognition dots. For example a red dot with a dollar sign on it might identify Perl fans, or a blue dot with `P' Python fans. A yellow dot with "MS" underneath and an international `forbidden' graphic over it might have ``I hate Microsoft!'' next to it. Or a green dot with "/." on it might be for Slashdot regulars. Or a big roman-numeral two (for the Second Amendment) on a blue dot for geeks with guns. You want to encourage people to design their own dots for constituencies you didn't think of in advance. People will get very creative and funny about this given half a chance. <sect>Staff Organization I've seen many technical conventions where the core staff gets run utterly ragged because they're rushing around fighting fires all the time. SF fans have found that a lot of this can be prevented by having a well-designed table of organization. Such a table has multiple functions. It defines areas of responsibility, so people know whose job a given task logically is. It helps pinpoint areas where staffing may be inadequate. And (perhaps most importantly) it helps the core staff figure out which jobs can be done by gofers. Gofer hours are cheap compared to core staff hours; you want to use gofers as far up in your organization as you can (but no further). At SF conventions there are generally three tiers of organization; the convention committee, the core staff, and the gofers. The convention committee sometimes incorporates themselves as the directors of a nonprofit organization formed to run the event; they're the people legally responsible for the convention. Their main job is to manage the core staff. The core staff are volunteers recruited before the convention by the concom. Core staff have full-time responsibilities at the con. Gofers (as we've discussed above) are part-time volunteers recruited at the convention itself. They're the footsoldiers. <sect1>The convention committee The convention committee (or `concom' in fanspeak) are the managers of the core staff. Here are some of the jobs that belong on the concom: <sect2>Convention chairperson The buck stops with the con chairperson. The concom votes on policy before the convention, but at the convention itself the chair's word is final. He is the chief firefighter and troubleshooter. It's important that the con chair not have other jobs besides being con chair. If he does, he will stress out and probably lose the big picture while chasing lower-level problems. <sect2>Convention vice-chair The vice-chair's job is to backstop the convention chair and stand in for him if necessary. It is not quite as critical that the vice-chair have no other jobs, but it is still a good idea to avoid this if possible. <sect2>Chief of programming This position is what technical conventions usually call ``program chair''. This person is a department head responsible for designing the convention program, recruiting speakers, and assembling the program schedule. The actual printing of the convention booklet is sometimes attached to the programming department. Otherwise there's a separate concom-level director of publications. The chief-of-programming job should not be combined with ops chief, hotel liaison, or vendor relations. <sect2>Chief of operations This person (``ops chief'') is a department head responsible for managing the core staff at the convention. Operations areas include gofer management, registration, security, signage, the con suite, management of AV equipment, and sometimes running (as opposed to planning) the programming. This job should not be combined with program chair, hotel liaison, or vendor relations. <sect2>Hotel liaison This person is responsible for relations with the convention hotels. This includes both arranging room blocking before the convention and dealing with reservation problems and facilities snafus during it. At large conventions, hotel liaison is a full department with several core staff attached to the director. This is mainly so at least one can be on call to handle problems at all hours. This job should not be combined with ops chief, program chair, or vendor relations. <sect2>Vendor relations This person is responsible for the show floor -- booth sales before the convention, troubleshooting vendor problems during it. This job should not be combined with ops chief, program chair, or hotel liaison. <sect1>Core staff Core staff are organized into departments, each directed by a concom member. Some departments (such as hotel liaison at a small con) can be one-man shows. Others (such as operations) need to be generously staffed. Again, at the convention itself the core staff should spend most of their time managing gofers who do the actual legwork. One of the functions of a ``gopher hole'' room is to provide a labor pool. <sect>Conclusion: Doing it with style If you work too hard, you are not working smart. The practices I've described are intended to help you work smart. One thing many hackers have with many SF fans is the combination of poor socialization with intelligence and a problem-solving attitude. While the poor socialization can make both kinds of attendees irritating to deal with, the intelligence and problem-solving attitude means they also tend to be very productive if you know how to manage them. Accordingly, work on your communication and persuasion skills -- and use them to offload as much of the work as possible onto gofers and random volunteers recruited on the spot. Don't think of this as laziness, think of it as self-preservation. </article> <!-- The following sets edit modes for GNU EMACS Local Variables: fill-column:75 End: -- >