I’ve been watching blog posts trickle out of THATcamps for years, and this fall I finally got a chance to attend one. As luck would have it, just as Carleton signed onto a Mellon Digital Humanities planning grant with Macalester and St. Olaf, a THATcamp popped up focused specifically on Digital Humanities and Libraries.
What a rich experience. It was populated by such a range of participants: people from large research universities, university presses, centers for digital humanities, OCLC research, major digital libraries, regular old librarians like me, and some disciplinary faculty, and some graduate students. It was a great opportunity to hear from people who are a few years ahead of where we are, to hear what questions they have now, what confusions exist that maybe we can head off before they become issues here, what workflows they’ve arrived at, what kinds of projects may be coming down the pike.
It was also an exhausting experience because the whole time I had to listen not so much to what, exactly, people were saying (since that was usually mostly irrelevant to me) but to patterns underlying the conversations: what kinds of services do institutions provide, are people mostly working in teams or alone, are the teams institutionalized or ad hoc, how do they negotiate the class differences between disciplinary faculty and library or IT partners, where do student research assistants fit into current work, what terminology do people use and where do confusions in terms exist… So many things to listen for and translate into my own context. And often I’d realize that information I’d dismissed earlier as totally irrelevant to me suddenly fit into a new pattern I was noticing, so by the end of the day I was pretty fried.
So what were some of the things that stood out as interesting or important themes or patterns? Well…
Have a Process — Allow for Exceptions
One session was about libraries becoming more involved as publishers since they often house the tools or manage the preservation and access to digital humanities projects. In my case, those tools would probably come from our IT department rather than the library. It was still really interesting, though, to hear the conversation slowly gravitate toward the consensus that in an ideal world institutions would have both a formal publication/preservation process and then also a sort of sandbox publishing process. This second process would accommodate projects that didn’t fit well into the formal containers (journals, books, wikis) or that couldn’t be evaluated in the same way prior to publication (peer review, for example). As one person said, often you have to build a thing before you know if it’s going to be worth anything, so the before-hand evaluation for publication process is largely impossible in these cases.
And in fact this became one of the major themes of the day for me. It seems that in order to support digital humanities projects, the goal is always to have the project based in tools, support structures, and data that are already present and ready for that kind of project. But there are also a lot of projects that simply won’t fit into existing structures, and so many programs provided capacity to work on these “boutique” projects. One woman had a phrase I really liked, saying that she looked at these as “first of a kind projects, rather than one of a kind projects.” The idea is to use these boutique projects to develop tools or services that the become part of the standard suite of support options, therefore taking less effort the next time.
Collaboration is Difficult and Necessary
This has been a theme not just of this gathering, but of every digital-humanities-related gathering I’ve attended or heard of. One humanist at St. Olaf said point blank that the humanities have traditionally been a realm of solo work so humanists don’t really know how to play well with others. They lose control of the process, the timeline, and the outcome, and the conclusions aren’t necessarily fully their own. Another humanist at a conference hosted this fall at Carleton spoke bluntly about how this “go it alone” attitude can easily translated into almost a master/servant relationship when collaborations mix faculty and staff because this relationship fits more easily into disciplinary practices that privilege solo work. “This is my project. Please make this thing happen in the way I want.”
Library Disciplinarity
While I was at THATcamp, I started thinking that one way to think about these projects so that they maintained their collaborative nature would be to think of it almost as interdisciplinary work, where the library is a discipline more than it is a service. The library has hundreds of years of disciplinary experience with finding, organizing, using, preserving, and making accessible digital and physical items. We study the rich complexity of the interstitial spaces between discrete pieces of instantiated knowledge. We study the socio-cultural practices that develop in these spaces and that draw dynamic connections between the items. To think of ourselves as “just” a service organization is to sell ourselves short and to relegate ourselves to perpetual outsiders in these ideally collaborative pursuits.
For this reason, I also really appreciated the ways that some institutions have “Digital Scholarship” programs rather than “Digital Humanities” programs. From the CS and Library perspectives, we bring very similar portions of our disciplinary training to projects from the Humanities and the Social Sciences, so there is really no need to have separate programs to support the various disciplines. (No need, that is, after the humanities have had a chance to acclimatize themselves to this new realm of scholarship. I can absolutely see how having dedicated energies directed to the humanities is important when first getting digital humanities off the ground.)
Some Practicalities
People at THATcamp were justifiably concerned about the sustainability and scalability of their programs. Some had decided that they would provide consulting support only or that they would cap the number of active digital humanities projects they could support at any given time (with a wait list for people once an active project graduated or died). Several found that they were in high demand to help scholars develop data management plans now that humanities scholars were applying for grants that require those, and that this had been an unanticipated and heavy demand on their time. And other libraries pointed out that rather than being all things to all projects, they would specialize — so Library A might specialize in text analysis and Library B might specialize in GIS applications for humanities. Most make use of graduate student work (we intend to employ undergraduates here).
It also became clear that initial conversations in the planning stages for a project should include some discussion of how permanent the end result is intended to be. Is this something closer to an item in our “circulating collection” that can be weeded when use dwindles and space gets tight? Or is this more like an item in “special collections” that requires greater commitment to long-term care? Who will be responsible for the server space and upgrades? Who is the intended audience and how will we get it to them? If it is interactive, how much of a change log should be available, and how much control do we exert over the kind and type of interactivity? Questions like this are not just procedural, it turns out, but can actually shape the project itself on a fundamental level.
And finally, it turns out that most projects need (but do not have) good graphic design. This is especially important for projects that involve crowdsourcing. And if you’re after interactivity, you’d best have thought about how to get people to participate (I’m reminded of Riedl’s research for this problem).
Comments closed
