Doing it by database
The way I've done it so far
When I (Rachel) have done programming -- the writing of panel descriptions, the figuring out who's volunteered for what, the recording of who's said they won't be on which thing with whom, all that stuff -- I've done it largely with a few word processored documents:
This lists all the current programming ideas that we've gotten, usually in alphabetical order by title of item. The full battery of information for a single programming item might be:
|23||How to sqork your fonspeam||Many people have argued over whether or not to sqork your fonspeam. We'll try to tease out some of the issues involved.||Hern Q. Forndoodle, Spake Thustran, Angela Q. Walrusnostril||Forndoodle requests not to be on anything with P. -- Notify sqorking lists about this|
So you've got the number of the programming idea (useful only to keep track of how many ideas you've gotten so far -- don't start referring to ideas by their numbers, because the numbers will change), what it's currently called, what it's about and who's been suggested for it. We also have a couple notes: that one of the panelists would rather not be on this panel with someone else (intentionally kept vague -- this document ends up getting seen by a lot of people, and it's best not to broadcast people's personality conflicts), and an idea for where to get more panelists.
Several months later, the same document will mutate to look like this:
|37||How to sqork your fonspeam||Sqorking your fonspeam has been the subject of furious debate recently. Although some people think that sqorking is necessary for any decent fonspeam, others say that fonspeams are best unsqorked. We'll try to avoid extremes as we discuss this subtle and nuanced issue.||Big||Bloomington||Friday, 9:00-10:00pm||Forndoodle requests not to be on anything with Plerb Quorn-friddle|
So now we've added in how big it is likely to be (that is, how big a room it's likely to need, which is also to say how many people we expect to be interested in the topic), what room we've currently got it assigned to (and if we've already assigned rooms, this must be from only a month or so before Minicon) and what time-slot we've got it assigned to (which also shows that we must be very late in the programming process indeed). We've also tweaked the description a bit (apparently, there was worry that the topic would generate excessively heated argument), and we got a panelist added, and gotten confirmations from the other panelists (showed by the fact that they're underlined), and gotten a confirmation from one who's willing and able to be the moderator ("m"), and one other panelist who's confirmed that they won't be on this panel. (Possibly because of the conflict with the new panelist, or maybe because the first one had a conflict, and now the new one could join; I carefully never state why people leave or join programming items.)
This document is by far the most important one in the way I've been doing programming. Keep one canonical version, save often, backup frequently, all that stuff.
Once you know with about 80% certainty who's going to be on what and when, it's time to create the actual grid. This is the big schedule that shows where every panel and programming item is, what times everything's at and (ideally) who's on what and more good information like dat. This grid should be put up on the web and turned into the pocket program somehow. It's also good to give it Dean in a database format so that he can turn it into a PDA application.
Programming notifications via e-mail
You should really e-mail all your programming participants about what items they're on, with whom, when, where, and about what. You should also send them whatever other info they need: where the Green Room is, when it's open, what can be found and done there; how to get in touch with you or the other programming staff during the con;
Turning all your information into