The Zombie Stack Exchanges That Just Won't Die
My digital library department is starting up an effort to create more online tutorials (text and video) on how to do common tasks in digital scholarship - using Google Maps to post a set of data points, using Zotero to publish an online scholarly bibliography, using Google Refine, etc. These would be targeted to our faculty that are starting to incorporate digital methods into their work. We think this content is valuable, and want to ensure we're able to keep it alive and relevant over time. What methods have you successfully used to ensure content like this is revisited and revised and kept fresh as it ages, while still continuing to expand the content base?
Jenn Riley
First, what doesn't IME work: assigning people responsibility for particular pages/tutorials/whatever. Update work isn't time-sensitive and it IS nitpicky and boring, so it slips people's schedules and never gets done.
What I'm pondering instead: periodic barnraisings, say twice a year or so, where everybody gets together, triages problems, and fixes content. With sufficient food and (nonalcoholic; we want the edits to be viable) drink, and people who like each other, this seems better than having the Sword of Obsolescence hanging over everyone's head indefinitely.
Updating resource guides is a specific student-worker project at the academic library where I work. It's assigned to an upperclass student who is responsible for checking links in the guides. We also have a spread sheet where library staff can add items for the guides, and the student worker puts them on the correct guide. It seems to work well.
When I worked for a university in the mid-to-late 1990s, we moved all of our documentation to Word Perfect (hey, I said it was the 1990s ... it was on a Wang before that) and generated an HTML version to place online.
In the process, we added a 'last reviewed' date to every document, rather than just a 'last modified' date. Then, over the slow periods (winter holidays, summer semester), we'd go through all of the files to see if they were still up-to-date.
We'd have the people working the front-line support (phones & walk-in tech support) comment on what people seemed to have issues with, and suggest revisions. All revisions were reviewed by the subject-matter expert in the group. If there were no revisions, the document was still sent to the subject-matter expert to look-over to make sure it was still up-to-date.
Someone (typically me) was assigned to make sure that all of the documents were reviewed and/or to hound the senior staff to get back their reviews/revisions.
So, the key points:
These days, with CMS systems, it'd probably be easier to keep track of how stale each file is getting, and what needs to be updated. Even if you're only reviewing stuff annually, with with so much stuff being hyperlinked these days, I'd suggest running linklint or some other link checker to make sure you're not suffering from link rot.
Video's going to be messier to maintain, as you have to either stitch changes in, or write a whole new script & get someone to do it ... and not all people are cut out for doing presentations.
I think one of the best ways to think carefully about what you really need and want to invest in creating localized documentation and guidance for. That is, everything you create is a liability of going out of date, so unless you have to give particularly important information about configuring a tool for use at your organization or unless your users have particularly distinct needs from other users I would suggest that you first try and point out to high quality guides and documentation that exist elsewhere.
When I worked on Zotero I spent a good bit of time reading a lot of the guides that libraries provided. Here are some examples of different approaches libraries took. In many cases, I think libraries would do better to spend time reviewing existing guidance documentation and then picking the very best information from around the web and pointing users to that documentation.
For example, in the case of Zotero, if there was some particular kind of specific use case you wanted to write documentation it would actually be much better to just sign up for the Zotero DokuWiki and write the guide on the Zotero site where 1) it would be much more broadly used and exposed as part of the Zotero documentation and 2) issues with it would get reported in the Zotero forums and it would be maintained by a much larger community.
So my overriding suggestion here is that the best way to maintain these kinds of resources is to make as few of them as possible and when you do decide to invest the resources in creating guidance either keep it light and institution specific or if you are creating something sizable consider composing it for a broader audience and sharing it with a larger community that could have a stake in maintaining it into the future.