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?