The seasons of programming

Historical note: This is basically how I (Rachel Kronick) did programming through the year as of around Minicon 43 (2008). Other programming staff have done it very different ways! But I thought it useful to document my way of doing it.

I didn't want to call this "the programming schedule", because that's a completely different thing.

How do you do programming through the year? What's the programming calendar like? Here's how I (Rachel) do it.

See Also

• Scheduling Notes (ca 2008)
• Room Requirements (ca 2007, Radish Tree)
• Documents or Database (thoughts on keeping track)
• Programming Supplies

At con

• Go to panels. Make notes. Figure out what's good, what works and what doesn't. Pay attention to how panelists interact with each other. See which people are good on panels, and who they're good with. When someone says "But that's another panel...", write down what they said. Many new ideas for panels will come to you at the con itself. Listen to people's feedback.

Throughout the year

• Keep a list of programming ideas. They will come to you at the strangest times. If possible, put them up on the website for the coming con so people can see that ideas are brewing.
• Be receptive to other people's ideas. Make your e-mail address available somehow to people who have ideas for Minicon. Put those ideas up on the web, too.

About four months before the con - serious brainstorming phase

• Prepare a document with all the current ideas on it. Every programming item should have a title, description, space for people to write their names in and space for notes.
• Using the above document, start asking people what panels and programming they'd like to be on. The main function is to start getting people to be on panels, but it also serves to get people thinking about Minicon and Minicon programming.
• Write down who has volunteered to be on what, and who has turned down what. Make notes about scheduling requirements ("Bob can't do anything Saturday", "Mary doesn't like morning panels") and other requests ("Don't put Bob on a panel with Mary", "This is Mary's second choice", "Bob is interested in a tangential topic, but not exactly this one", etc.).
• As people give you new ideas, write them down. Put them up on the web as often as possible (on the Wiki, for instance).
• Hold brainstorming meetings. Organized programming committees have been known to do this at regularly scheduled programming meetings. A simpler way to do it is to piggyback your programming brainstorm on regular concom meetings. Brainstorming is fun, so you can usually get people to participate even after sitting through an hour or two of concom meeting.

Rachel: "I usually do these things starting at the MnStf Halloween party."

Sharon: "I like to start brainstorming at the Minicon Dead Dog party. But I guess I'd agree that the Halloween Party is a good marker for shifting it into a higher gear."

About three months before the con

• Meet with your programming minions. Go over the complete list of programming ideas and think of who would be good for what items. Figure out general groups you want to write to (authors, musicians, the Lady Poetesses from Hell, etc.) and contact them with lists of specific programming items you think they'd be interested in. Divvy up who will contact whom. Yes, programming is primarily a management job.
• Contact each of your Guests of Honor, introduce yourself, tell them how excited you are to have them and open the dialogue about how much programming they would like to do, and what sort of programming. There are other options beyond panels - presentations, slide shows, round-tables. Let them know when programming starts on Friday and ends on Sunday, preferably BEFORE they have made travel arrangements. If you have a good start on programming ideas now is a good time to present some for consideration.
• Continue taking in ideas. Keep the web-page updated as often as possible.
• Start the process of contacting everyone who's been recommended for anything. This is by far the largest part of the job. It will take many, many hours of writing back and forth: asking people to be on things, asking again, getting corrections, taking input on descriptions, etc. It starts off at about five hours a week and ramps up to about 20 a week in the month before the con.
• Keep track of whom you've asked about programming, and who has said they'd be on what (and who has said they won't be on what), and what their requirements are.

About two months before the con

• Continue the dialogue with the GoHs. Find out what their scheduling requirements and preferences are. I like to ask straight out - are you a morning person or an evening person? If you have a GoH who is up with the dawn you might as well put him or her on some 10am panels and make the morning people happy. On the other hand, if your GoH is the type who likes to close down the bar, be nice and don't schedule them on early panels. Would a GoH like to speak at Opening Ceremonies? For that matter will they BE at Opening Ceremonies? Double-check on their arrival and departure times. If possible, run all your GoH programming ideas past the GoH before committing to it, although most GoHs will be satisfied to at least KNOW what you put them on before they get there.
• Make sure you know what everyone's time requests are, to the greatest extent possible. Some people like to be on four panels back-to-back; others want to be on nothing before 2pm; others need a two-hour break for lunch on Saturday; others want to be on no more than three panels throughout the weekend; others need to be on airplanes by noon on Sunday; etc.
• And keep track of other requirements: "Don't put me on a panel with Bob", "Don't put me and Mary on panels simultaneously, because we're married and one of us has to be available at all times to take care of our kids", etc.
• Also keep track of who's volunteered to moderate, who doesn't want to moderate, and who would be good to moderate.

About a month before the con

• Start hashing out the final panel compositions. Determine, with your programming sub-heads, who will work best with whom.
• Decide who the moderator for each panel will be. Ideally, this should be a question of writing to the people who you think would be good and asking them if they'd like to moderate. Unfortunately, responding back and forth in a timely fashion can be hard at the best of times, and as the crunch starts coming, you may be tempted to just assign people as moderator (hopefully helped by having earlier asked who would be willing to moderate).
• Determine roughly how big a draw each programming item will be. Your best guess is as good as it gets; there will always be panels that end up more popular or less popular than you guessed. A couple rules of thumb, though: anything with a Guest of Honor on it will be much better attended than anything without; and things that lots of people wanted to be on will generally also be well attended.
• Start hashing out the final schedule (that is, what panels will go into what time-slots). This entails balancing everyone's scheduling requests, finding rooms of the correct size for each (as determined above) and making sure no one has conflicts. Don't schedule a person for two things at the same time, of course. Also try to avoid putting married couples on panels together, and if they have kids who need attention, avoid putting them opposite each other in the same time-slot (someone has to be available for childcare). Try not to schedule your Guests of Honor too tightly, and leave them time to eat meals.
• Stay in touch with the GoHs throughout the scheduling process. Basically, you'll be building the bones of your schedule around the GoH items. Double-check on GoH arrival and departure times. If they say, "I'm leaving at 5pm Sunday," be sure you know if that's when their plane leaves or when they are leaving the hotel for the airport. It's awkward when the GoH has to leave in the middle of Closing Ceremonies.

About two weeks before the con

• Send your final versions of the programming schedule and descriptions to the folks putting together the Program Book and the pocket program. What are those things?
  • The Program Book is the big, probably letter-size book that includes Guest of Honor bios, messages from the con chairs, lots of nice art, and full descriptions of all programming. This is where people will usually look first for the full descriptions of programming items. Also, this document should ideally have all the moderators listed in it. For a recent example, see this scan of the M48 Program Book. Because this document is so involved (many pages, stapling, sometimes color, etc.), the program book generally takes longer to print.
  • The Pocket Program is the one-sheet document that includes a grid of programming items, maps, hours for various con functions and other helpful quick-reference information. It generally includes only the titles of programming items, not the full descriptions or names of participants. Here are a couple recent examples: M49 Pocket Program, M48 Pocket Program. The pocket program isn't as complex to print, as it's generally just a single page, so lead times are shorter. For this reason, the pocket program sometimes gets printed much closer to the con itself, and can include more up-to-date information than the program book. See the pocket program's page on this wiki for more information.

Note that the person doing the pocket program may be different from the person doing the program book. They may also have different document requirements from what I've described here. Make sure you know who you're supposed to give which documents to, and when.

• Print up some BIG copies of the final schedule. (Like, several feet by several feet, if possible.) One can go in the Green Room, and others can go up on the walls in the convention space. The pocket program should have the schedule in it, but huge versions are also very handy. Recently we have had three of these: one in the Green Room, one in the Consuite and one on the main bulletin board near registration. This seemed to be the right amount. See also Supplies needed for Programming.
• Print up the badge labels. What are badge labels, you ask? They're little sticky labels that panelists can stick to the backs of their badges to remind them when their panels (and other programming) are. They should therefore include the following information: Who the label is for; which programming items they're on; when the programming items will happen. If there's space, you may also want to include the descriptions for the panels. How do you distribute the badge labels? Some people say you should just stick them directly on participants' badges during the registration packet-stuffing process; others say you should distribute them in the Green Room, so that participants can affix them how they like (or not at all, if they prefer). See also Supplies needed for Programming.

About a week before the con

• E-mail every programming participant with their final schedule. Mention when and where each programming item they're scheduled for will be, and give the descriptions and final panel composition for each. Also ask them to be early if possible, and mention how you intend the Green Room to be used, where it is and what its hours are. Let everyone know how they can get in touch with you at the Con, if need be (emergencies do crop up).
• Print up tent cards for programming participants. See also Supplies needed for Programming.
• Print up room schedules to post by each programming room on a daily basis listing the items taking place in the room, times and participants. Note: if the room has two doors, print up one schedule for each door. See also Supplies needed for Programming.

About three days before the con

• Panic. This is about the time that three people you desperately wanted to be on various panels will finally get back to you and say they'd like to be on all of them, but they all have to be Friday night. And you will inevitably find that you've scheduled Mary for three panels, simultaneously, on Sunday morning even though she's only going to be at the con on Friday. And you've got Bob on a panel with Tim, even though they've vowed to fight to the death with bat'leths if they come within twenty feet of each other. And all your guests of honor are sick.
• Print up table tents, room schedules and badge stickers (if you haven't already done this). Get together the other supplies you'll need.

At the con

• Go through your A/V setup and test things. Panelists will inevitably come with laptops that are incompatible with all the projectors, or no one's tested the projector and it's got a burnt-out bulb, or the cords aren't long enough, or whatever. If you have panels that depend on A/V setups, it's best to get the wrinkles out ahead of time.
• Be available for all the little emergencies that will crop up. Think on your feet.
• Make sure that table tents and water glasses are ready before each panel. I [sharon] like to put all the table tents for the day's panels in a stack on the corner of the dais table at the beginning of each day (or better yet, the night before so you don't have to get up before 10am every day!). Theoretically the hotel is supposed to send somebody in to replace the water glasses before each panel, but it's a good idea to have somebody check each room at panel switching time to make sure this happens.
• Room census - if you're hanging around the programming area anyway, why not do a room census? Just pop into each room once during the panel and note the size of the audience on your handy pocket program. Great data for scheduling next year.