In pondering this proposal, I’ve come up with four basic types of documentation that I think are relevant to digital humanities projects.

• supporting creation of scholarly output
• supporting reporting to funding agencies or academic departments
• allowing sharing one’s research methodology with other scholars
• informing and educating system administrators about the system-level requirements of the software itself

All these types of documentation are important, but I think it’s time to start talking with each other about that last type. We all want the results of our work to survive and mature, and one of the best ways to insure longevity and sustainability is to properly document system-level requirements—software dependencies, negotiated service level agreements, database design, etc.. Improving our communication with our IT system administrators ensures that we can meet as equals, moving away from handshake deals and hopeful bribery with baked goods as a means to attempting get the support our projects require.

We’ve learned some hard lessons at UVa Library about the sort of documentation and process definition that are required for long-term support of our digital tools and interfaces, and I’d love to share these with anyone who’s interested. Just as importantly, I’d love to learn from other attendees experiences creating usable system documentation for their projects.

related to:  karindalziel’s  session proposal

Although I have attended THATCamp the two years previous to this, this is the first in which I am fully immersed in the day to day building and maintaining of websites.  Because of that, my view of what to talk about has become a bit more… pragmatic. Some days I manage to try to ask bigger questions about what we’re doing and why-but most days I am fixing broken things (hard) and trying to not break my own things (harder). Migrating old sites to new technologies also takes up a good deal of our time.

So, the session I proposed was on the life cycle of digital humanities projects- specifically how to design and develop for the eventual long term preservation of a project. Bethany Nowviskie is addressing this in part with her work on Graceful Degradation, but I am also interested in what we can do at the beginning of projects to make them easier to maintain indefinitely. I’m not sure exactly what this might mean. Some ideas: limiting the kinds of technologies used so that projects are easier to support; pre-building a planned HTML only version, to be deployed in case of a loss of technology. (Also of interest is Hugh Cayless’s session proposal). Some sites don’t have such easy answers, like older GIS sites that depend on a specific commercial server. Other aspects include documentation and commenting code (something we have lacked due to heavy workloads around here). I am curious how others in similar situations deal with this- are there standards in place, or do you decide on documentation and technologies on a project by project basis?