Programming Head - Job Description

Overview

Starting this on April 6, 2015. The goal is to have a comprehensive description of what is involved in running the Programming Department for Minicon, a mid-size regional science fiction convention.

Programming Head is a big job, arguably the biggest of all the department heads besides the chair. Hospitality (bar/consuite) is huge at the con and in the month or so preceding, but not too much of a burden the rest of the year. But Programming keeps demanding time and energy all year long. The busiest time for Programming is the last 6 weeks before the con, where it can easily become a 40-hour work week. There are significant job responsibilities at the con itself, although the more thorough the preparation before hand the fewer the at-con emergencies will be.

See Also

• The seasons of programming - a suggested Programming Timeline

Pre Convention Responsibilities

• Assemble a Programming Committee
  • Choose people with a variety of interests and talents. If, for example, you primarily read fantasy, it's good to have sub-heads who primarily read SF. If you are primarily a comics and filk fan, try to have sub-heads who cover gaming and costuming. Also, if you're really good at communicating but not good at scheduling, try to have sub-heads who make up for that.
• Go to as many concomm meetings as you possibly can. As the head of programming, a ton of things will hinge on decisions you make, and people will need a lot of information from you. Examples:
  • A lot of departments will want to know when you're planning on having big Guest of Honor events, so they can make sure to not schedule their big events at the same time.
  • Departments will want to know pretty early how you're organizing the time slots for the schedule. One-hour programming items with half-hour breaks in between has become the norm, but you may do it differently. And other departments will want to match their schedules to yours as much as possible.
  • Generally get to know your fellow concomm members. It's important that you all work comfortably together, and they will need to be able to find you regarding emergencies/last minute decisions/general queries at the con, so it's important that you all recognize each other. (Minicon hasn't done walkie-talkies lately, and finding people has tended to be very loose: "Have you seen Rachel lately?")
• Start a list of programming ideas (as soon as possible after the previous con)
• Collect and write down ideas as they come to you. Keep a list in your phone or notebook or whatever, and write them down when they come to you, then add them to the wiki when you can.
• Add to idea list with formal and informal brainstorming sessions
• Clarify others' suggestions as best you can. (If you later can't tell what a given idea was about, either turn it into something workable, or chuck it.)
• Research the Guests of Honor
  • Think of panels and other programming items they would be interested in
  • Think of panels and other programming items that could be related to their interests/work/etc., even if the GoHs aren't going to be on them
• Publish an online list of programming ideas (often referred to as the "Programming Online Brainstorm")
• Solicit interest in panels
  • Ways to do this:
    • Emailing everyone who's expressed interest in being involved with programming (by checking the appropriate box on their registration form)
    • Sending out notifications that programming sign-up has begun (notifications should go on the Minicon/Mnstf Livejournal and Dreamwidth accounts; Facebook; Twitter; the Minicon website; etc.)
    • Targeted email to people you know could be good for particular panels
    • Personal email with Guests of Honor -- make sure to ask clearly what sorts of panels they'd like to be on, if they have any additional suggestions, etc.
    • Some combination of the above
• Keep up communication with programming participants. Make sure they actually want to be on the items you've got them scheduled for (not always guaranteed, because descriptions sometimes change after you've scheduled people for panels). See if they have ideas for other good panelists. See if they'd like to tweak the panel topic.
• Ask interested participants to tell you their conflicts and scheduling preferences, such as people they don't want to be on panels with, times they're not available, etc.
• Collect schedules from other departments that will have them: movies, music, kids' programming, etc.
• Keep in touch with other departments as their schedules change, so you can integrate and adapt to them
• Create the final programming schedule. This is a complex process, involving a lot of cascading scheduling conflicts, etc. etc.

1. Judge, based on general interest, which programming items will be huge. These should be in higher-capacity rooms, and you may also want to be careful not to schedule these opposite each other.
2. Slot guest of honor programming into the grid first
3. Generate initial layouts of the grid
4. Keep participants' requirements in mind
5. Have your programming assistants look at the grid and help you spot conflicts

• Notify all programming participants of their final schedules, including:
  • All panels they're on, who they're on the panels with, who the moderators are, where the panels are
  • Existence of the Green Room, and its purpose, hours and location
  • How to let you know if they discover any errors/conflicts
• Coordinate last-minute updates
• Pick moderators for panels
• Notify moderators that they are moderators
• Give panelists contact information for other people on their panels, so they can pre-discuss things if wanted
• Give final copy of the full programming schedule, with panel names, times, locations, panelists, moderators, etc. etc. to the Program Book creator
• Give final copy of the programming schedule, including panel times, time & locations to the Pocket Program designer
• Print table tents (the folding cards that give panelists' names, giving audience members a visual reference to who is who)
  • At a minimum, tents need to list the name of each programming participant in large, easy-to-read type
  • Other good things to include: on the other half of the paper, where the participant themself will see it, list the panel name, topic, panelists and time slot; if possible, include the full description of the panel, so panelists can remind themselves of what they're supposed to be talking about.
• Print badge labels (little stick-on labels for programming participants' badges, so they have ready reference to what programming they're on)
• More to come...

At Con Responsibilities

• Test A/V setup for room(s) with A/V -- make sure projector is ready and working before any panel needing a projector
• Monitor panels and see how popular each programming item is
• Note which panels work well, which panelists work well, and which moderators work well
• Put out table tents
• Generally monitor programming and see how things are going: are panels too loud? Any panels that panelists didn't show up for?