Some Thoughts on Transparency in Digital Scholarship

Hello, all! I hope your semesters have gotten off to a good start. I am in the throes of reading, writing, and editing, with two articles I’m waiting for proofs on, two edited volumes either waiting for initial submissions or final edits before we submit it to the press, and a conference I’m supposed to attend at the end of the month. I’m also hoping to get another article finished and a chapter and the introduction of my dissertation edited into a decent form for the book on Mary Magdalene I’m working on. Not to mention continuing transcription and troubleshooting on the Minor Works of John Lydgate, in preparation for submitting the current version of the site to the Medieval Electronic Scholarly Alliance and the publication of the Long Melford verses alongside my article in the January issue of the Journal of Medieval Religious Cultures. It is all a lot of work, and I always worry that it looks like I’m spinning my wheels right up until the point where they gain traction – and then it will all happen at once. This can create the perception, which I’m sure a lot of you have experienced, that you’re doing an awful lot of work but it doesn’t feel like you’re seeing any benefit from that work. For this post I’d like to talk a bit about the implications of that sort of wheel-spinning effect in digital scholarship and what you can do to make the work you do transparent.

In my last post, I used the analogy of iceberg to describe the amount of work put into a digital project versus the perception of that work. As we’re all taught, only a tenth of the iceberg is visible above the waterline. That tenth is what people see and what, ultimately, we’re judged on—which is a truism that holds across articles, books, conference papers, and digital projects. However, there is a difference between the first three and the fourth: the citations used in an article, when combined with notes and the reader’s own judgement, give a sense of how much time and effort went into researching and producing the piece. That research, while not foregrounded, is made visible in a way that it is not in digital scholarship. There, quite often the means to solve a problem is a process of experimentation that does not get easily cited. Add to that the problem of users and readers who underestimate the complexity of a programming problem (even a relatively simple one, such as the ones I tend to run into in my work) because they’re used to experiencing and not programming applications and you end up with people either vastly overestimating your skills and the amount of work you put into a project or underestimating what it took to accomplish something because it seems so simple once it’s actually put together. I’m going to leave the latter to another post and talk a bit about how I attempt to combat the former.

Before I began any work on the site, I sat down and wrote up a series of design principles I intended to follow. I’ve seen a lot of digital projects undergo some significant scope creep, and I wanted to make sure that I did not have that happen to me–especially since I was intending to do the work as a one man shop! These, in turn, evolved as I worked on the project into a series of axioms that I use both when producing my own work and in evaluating other people’s. I strongly suggest that you begin your project by writing out your own version of a set of design principles, and that you make those principles public. Not only is it a good way to organize your thoughts, it also helps you to get into the practice of being transparent in your work. That transparency will help to shine a light on the otherwise-obscured parts of the iceberg, and make a casual user or reviewer more aware of the amount of work that has gone into making your project both useful and functional.

In the Minor Works of John Lydgate, that transparency begins with the “About the Archive” page I linked to above, but it goes beyond that to also discuss my process of transcription, the line-reading comparison feature, and once I have it written up both the full process I used in developing a three-dimensional model of the Clopton chantry chapel and the raycasting feature I mentioned in my last post. I do this because I believe that the action of developing a digital project is itself a type of theoretically-informed editorial mediation, and like any intersection of theory with your work you have to articulate what exactly the theory is and the kind of work it is doing. Doing the work is dry at times and I will freely admit that I wonder if anyone will really read it, but when the time comes to articulate why using <sourceDoc>, rather than <text>, as my base in TEI is an act of remaining as close to the orignal manuscript as possible having done this work already for a public audience will make that more scholarly articulation much easier.