Documents or database?

From Minn-StF Wiki
Jump to: navigation, search

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:

Programming suggestions

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:

Number Title Description Suggested participants Notes
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:

Number Title Description Suggested participants Size Room Time Notes
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. Hern Q. Forndoodle, Spake Thustran, Angela Q. Walrusnostril, Plerb Quorn-Friddle Big Bloomington Friday, 9:00-10:00pm Forndoodle requests not to be on anything with P. -- sqorking lists have been notified

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 confirmations from the other panelists (showed by the fact that they're underlined), 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.

Programming grid

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. Also include who the moderator for each panel is, and if they're doing a signing or reading, where and when they're doing them. 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; what to do in event of conflicts; how to know what the canonical, really correct schedule is; requests for volunteers; etc.

Sticky badges

Turning all your information into a format that's usable to make badge labels (the sticky labels that programming participants should get to remind them when and where their panels are) can be quite a chore, especially if (like me) you've done it all with word processor documents. Which leads us to...

Doing it by database

Really, all the programming information should be collected in a database. Fundamentally, it is a database -- who's interested in what, when, where, with whom. And so many of the end-products work (PDA apps, badge labels, e-mail notification, etc.) need databases to work anyway.

The thing is, I'm not all that good at databases, and didn't have time to find people who were. However, if you can do it, I expect you'll do a much better job than I did.

Sharon adds (2015). I did create such a database and it is available to anyone that wants to use it. Limitations (besides a few rough edges) - it's written in Microsoft Office 97 (Access). This is totally incompatible with the newer Microsoft Office, and may only work on Windows XP. There are a few old laptops floating around Minnstf with XP installed where this database can be used. If anybody wants to write an updated version for a newer database program I'd be happy to help.

Pre-existing resources

In fact, using databases to do programming is such a time-honored and wondrous thing that there are pre-existing tools to help people do it:

  • The Comprehension Convention Engine is a Windows-based, proprietary but free system for dumping in data and coming out with all the wonderful stuff you need: schedules, pocket programs, etc. The ability to automatically resolve scheduling conflicts has got to be music to any programming head's ears.
  • Zambia, from the Arisia folks, looks like it's more open-source in nature but less complete in function.
  • Since I'm linking to their website anyway, I should link to Conrunner.net's Programming category, which has lots of wisdom.
  • Many other cons do their programming via database. In the area, check out Wiscon and Convergence, both of which are living in the Internet age and use web forms for programming participants to register for programming.
  • Another useful database system for programming a con is OpenConferenceWare.