One of our goals with Mobile Voices has been to develop an effective process for the Popular Communication Team (PCT) to be able to participate in the design of our Content Management System (CMS). We determined early on that we would be customizing Drupal (http://drupal.org), the popular Free Software CMS, for our needs. The question was, how could we create a workflow whereby the developers working on the customization would respond to the needs expressed by the PCT, rather than simply to the researchers’ preconceptions about what might work best? What we came up is the following:
1. We set up the ‘bare bones’ CMS. We determined early on that we’d be using Drupal, partly because we knew we wanted to develop our own CMS using Free Software, our team had experience with Drupal and connections to developers who work on Drupal-based media sites, Drupal is becoming widely adopted by newspaper site developers, and a number of kindred community media projects are using Drupal (for example, see the Media Mobilizing Project: http://mediamobilizing.org). Obviously, this decision wasn’t participatory, but we thought it would be best to start with a base.
2. We set up a Redmine issue tracker: http://dev.vozmob.net. Our developers suggested this as an increasingly popular, Free Software, project management tool that would be useful to keep track of feature requests and bug reports, assign tasks to individuals, log hours, and otherwise facilitate our CMS development process.
3. Popular Communication Team meetings generate feature requests and bug reports. Each Tuesday evening, when the PCT meets face to face for the workshop, someone from the research team takes on the responsibility of paying attention to what the PCT members say about how the system is working, what features they would like to see implemented or changed, and whether anything is ‘broken.’ This sometimes happen formally, when we go around the circle and each person describes what they like and don’t like about how the CMS is working, but more often it happens informally, as issues emerge during conversation or during the hands-on portion of the workshop. During or after the workshop, we translate this into specific feature requests or bug reports to enter into Redmine and assign to the appropriate developer.
4. Developer meetings clarify feature requests and bug reports, determine paths to solutions, and assign responsibility to developers. We have one developer (Mark) in the Bay Area, one (Gaba) in Uruguay, and occasional participation from others (Eric, Chris, Josh) here in LA. Each Thursday at 2pm Pacific we meet via Internet Relay Chat, on irc.freenode.net in channel #vozmob. In these meetings, we review our progress, discuss new feature requests, research various possible solutions, and come to consensus on who will do what. Everyone uses redmine to report on the progress of specific issues.
5. Repeat steps 3-4!
I’ll write more later about this, maybe describing specific examples of a software design issue that was resolved through this process, but this is the general overview. It all sounds so simple, doesn’t it? Now I think it’s time to head off and research whether the new Flash Vorbis player is developed enough to allow us to use ffmpeg to transcode all incoming WAV files to ogg vorbis so that they can be embedded in the slideshows using mailhandler to post to a content type node that will have a dedicated template calling jquery, with a browser detect so that users of Firefox 3.1 can play the vorbis natively but otherwise trigger flash … or should we be transcoding to mp3 and creating a tab that will let those users who select ogg download or play in browser that way … so that we can resolve the PCT’s request that one click will play images and sound at the same time… argh! If you want more detail, check out Issue #16: http://dev.vozmob.net/issues/show/16