This is a description of what has been done to coordinate the information gathering of various Independent Media Centers in the past, along with suggestions for future IMCs.
An IMC could save a lot of effort and do a lot more with its content if it did a better job of thinking out its information infrastructure before things heated up. This might entail considering dispatch its own entity with its own planning needs, budget, working group, etc, or it might mean simply having the different working groups coordinate better and plan some kind of strategy in advance.
The website has a lot of material whose power could be enhanced by linking it to similar content. For instance, a print story on a puppet center shutdown could be posted along with an audio and a video clip. This would be easiest to do if there was better coordination between working groups. People have suggested that "teams" be formed to send out to each event with a rep or two from most of the working groups to facilitate the clustering of content.
As I see it there's a couple of things to be done to make this happen. (I'd love to hear additional suggestions.) First, you could run on the dispatch model, where there is one "working group" designated to keep track of teams, direct additional reporters to a team, and work with the media working groups of activist organizations (DAN, IAC, R2K, etc.) to ensure that we have a better sense of what's going on. I'll say more about what we've been doing along these lines in a bit.
Working group and general meetings could be better scheduled to make a decentralized system of assignments easier to run. In Philly, the general meeting was held BEFORE the working group meetings, which struck me as odd. If working groups met first, they could set up assignments then; at the general meeting there could be a brief rundown of the next day's stories and who was covering them from each group. People could then get in touch with team members from other working groups after the general meeting. I think this would give us a much-needed sense of the "big picture" of what we're covering.
I would recommend the dispatch model, myself (although that doesn't necessarily exclude the "decentralized" model). I don't like centralization, but in the case of protests where we are monitoring fast-moving actions and sending reporters out to cover them we may lose time and footage if reporters don't have some way of finding out what's up without coming back and tracking down their working group coordinator.
In Philly the print and photo teams were masterfully well-coordinated-hats off to Amy and all the other folks who made that possible. This was because they kept a database with information, entered the night before or even days in advance, on who was going to cover which stories and who they'd be teaming up with. The audio team also tended to plan things out a day in advance and knew who'd be where. Video, by contrast, seemed to run on a more decentralized model- it was my impression that the group was already broken down into teams working on a number of small projects. These projects tended to take care of their own business, and they weren't always able to give dispatch a sense of who was where as a result.
In the past, a big IMC-wide list of stories has been written out on a large piece of paper (usually in the evening or morning) and posted on the wall to give people a sense of what's being covered on a given day. The advantages to this system were that it was easy for people to plug in-all they had to do was go to the wall and see what was there-and it was relatively uncomplicated.
Dispatch in DC and Philly also tracked activity on paper logs kept by the phones. The logs had space for people to record the who, what, where, and when of the information we received--calls we got from folks in the field, R2K, and live mainstream media coverage. We stuck post-its to a blown-up map of the city to give us a good sense of where things were happening when we needed to give folks directions.
Between the big paper and the little papers, this system was maddeningly messy. So in a fit of pique in Philly, I ditched the paper system, frustrated with its drawbacks. Some of those those being: a) you can't make the paper wall list grow, shrink, or spontaneously erase errors or completed events, so the information quickly outgrows the paper; b) the paper phone logs also have little room for expansion and c) they're not easy to search (if we wanted to tell anyone anything useful about where a protest was we had to dig through mounds of old records); d) It's hard to make sure that people actually use the wall list; e) Dispatch is frequently not close enough to the wall list to make use of it; and f) the map quickly gets clogged with old post-its.
I cobbled together a FileMaker? Pro database instead. The database had space for the date, time, and location of an event; a brief description of the event; contact information for organizers involved with the event and IMC folks knowledgeable about it; and a field for information on who from each working group-print, photo, video, and audio-- was working on that story.
Within each record there was also space to write in updates on an event as it happened-new information on location and police activity, indexed by time. This was achieved by means of a multi-celled record, a feature which more recent versions of Filemaker might not have. In the future I'd like to have this feature work on a relational database, which I'd forgotten how to do in Filemaker at the time.
We also made up a database of cel phone numbers (and we should have made one up for who had a car-in places like Los Angeles a drivers list is going to be SO VITAL, as LA folks have probably found out), but I don't think we used it well. If I had my druthers the main database would be relational and draw this information out of the cel and car databases.
There were two ways to view the information in the database. The first was by record, sort of a Rolodexy view of all the information pertaining to one event. The second was a listing of selected information on a series of events-say, time, name of event, and who was going to it. The latter was supposed to lend itself to searching current events, viewing at a glance where we needed more coverage, and printing out a transparency which was going to be projected on the wall, which people could use to sign up much in the way they could add to the old paper wall list. (I would love to hear from Holly whether that part was ever useful or even used; in fact, Holly, if you're out there and could give me a rundown on what you felt were the weaknesses or difficulties presented by the database in general that would be swell.) Obstacles to the transparency system: we had trouble finding a working printer or copier, and I think the overhead bulb may have burned out once or twice.
People were confused as to why we'd replaced the paper list with a transparency, which would have worked in a similar way and in the end was worse because of technical difficulties. My idea was simply to make dispatch's list of the events correspond with the list everyone else could see. If you print out a transparency once an hour, let people sign up on it (so they don't have to come to you and bug you if they're going out), add their written info back into the database, and make sure that new events come through you and don't go direct to the transparency, keeping track of what's going on should be a little neater.
This Filemaker-and-transparency model was not my ideal, but it worked ok. Really what I would have liked to have is a video projector which could be hooked up to a computer showing a real-time listing of stories at all times-some view of the database which could be updated by dispatch and reflect the updates just after they happened. I would suggest we have one computer and a video projector dedicated to displaying a report on the events of the hour on the wall at all times.
To make things slightly more complex, we might also try making a tipline on the web as well as on the phones, whose info would then get dumped directly into a web/networked story tracking DB. This way people could access and at least look at the story suggestions from various terminals without having to talk to dispatch, if they didn't actually sign up themselves. Problems with this might be crashed DBs and data corrupted by people entering multiple records/ adding erroneous data.
Such a DB, I suppose, could eventually spit the completed story/associated materials back out onto the web? I don't know if it would be wise to give the tech team any more stress, though; they usually have their hands full. If we were working off a story tracking system having it suddenly go down would suck, so perhaps keeping it to a few simple networked computers with Filemaker would be ideal.
Philly seemed to work pretty well without even making the database visible to everyone. When people wanted a story, they'd check in with me or Holly, and using the database we could look up info, add info if they had any, and help them hook up with the other folks on the story they planned to cover.
In sum: I would recommend that any large IMC plan to provide at least one computer and a printer for a dispatch team.
In formalizing the "assignment" process I'd be concerned with losing some of the delightful messiness and spontaneity of an IMC. I know I feel comfortable at the IMC precisely because there's a lack of structure; I wouldn't want people to feel tied down because of their assignments. At the same time, I think we waste a lot of energy in duplicated coverage and lose a lot when we miss events that reporters haven't flocked to.
update: to get an overview of how dispatch could work, have an look at DispatchWorkingGroup