In the preface to the 1831 edition of Frankenstein, Mary Shelley describes the origins of her novel in a “wet, uncongenial summer” at the Villa Diodati. There, living with Percy Shelley, Byron, Polidori, and an unacknowledged Claire Clairmont, she found inspiration in “many a walk [and] many a drive” with her husband, and in the “many and long … conversations” she overheard (and, let’s be honest, probably participated in) between Lord Byron and Shelley. The story of Frankenstein, she suggests in this preface, is less the result of her own genius than it is the happy outcome of spending time with and working beside other talented people.
Regardless of how true this story actually is, I couldn’t help but think fondly of it as we launched our class encoding project for the Shelley-Godwin Archive. Not only were we translating into xml the very manuscript that Mary Shelley had been producing during that long, rainy season, but we were doing so in an environment just as predicated on support, encouragement, and—most importantly—collaboration as the one that Mary Shelley tells of finding at the Villa Diodati.
In carrying out this project, we teamed up not only with each other, but also with a number of students from Neil Fraistat’s Technoromanticism course at the University of Maryland. (Those students have written their own excellent responses to the encoding experience on their Team Markup blog.) The project provided us not only with an irreplaceable opportunity to study the nuances of Mary Shelley’s manuscript—to see her doodles and cross-outs, to discover Percy Shelley’s revisions, and to witness the creation of one of the most famous creation narratives of all time—but also to invent for ourselves a successful system of teamwork and support. As we look to continue this project in the future, I thought I’d share some of the most important lessons this particular partnership has taught me.
1. Ask for help when you need it. When I first volunteered to coordinate the encoding project, I assumed, with cringe-inducing naiveté, that I’d figure it out as I went along. I knew html, I reasoned, and xml didn’t seem that different. How difficult could it be?
I got my answer almost immediately. It could be very difficult. What was this “Github” and how did I set it up? How was I supposed to renew my subscription to Oxygen and why wasn’t it opening properly on my computer? Where were the transcription files that we were supposed to encode? And where—and what—was the schema? It didn’t help that I was supposed to lead a team of three other students, many of whom knew little more than I did.
It became clear to me frighteningly quickly that I was going to need help. Lots of help. I began questioning everyone I knew (or didn’t know) who seemed to be comfortable with computers, from the Scholar’s Lab staff and the current NINES fellows to friends of friends and tech support. I checked the project GoogleDoc, read and reread the Encoding Guidelines, and sent a ridiculous number of emails to Amanda, UMD’s own, amazing project coordinator. I read internet how-to pages until I felt that I knew them by heart.
And then something amazing happened: I actually started to understand what I was doing. Not always completely and not always terribly well, but enough so that I could mark up a page in Oxygen and push it on GitHub without breaking a sweat. More important, I found that I, too, could offer people help when they needed it. I was still far from an expert, but my willingness to look like an idiot had allowed me to become a successful—and, dare I say it?—helpful part of a collaborative community.
2. Work together as much as you can. It turns out that a successful markup team, much like a successful sports team, must be able to work together. As my little league coach used to remind us, it doesn’t matter how good you all are individually if you can’t play well as a group. In the case of my little league, this was a moot point—individually or together, our athletic skills were basically nil. In the case of the SGA encoding project, however, teamwork proved to be key.
At UVa, we accomplished this by doing most of our markup work together. Because our group size and our encoding requirements were both relatively small, we were able to arrange meetings throughout the semester to do our work together. This meant that if questions or problems arose, we had teammates present for immediate feedback and support. If someone faced technological difficulties—as happened frequently during the early days of our project—we could work together to engineer a work-around. At the very least, we had someone to talk to about Frankenstein’s poor decision-making and our dislike of ptr tags.
When it came to working with our counterparts at Maryland, however, the process was more complicated. I stayed in touch with their project coordinator frequently by email, and she was able to provide us with key information about everything from their team’s progress to unanticipated schema changes. We also engaged with the UMD students through the project GoogleDoc, which contained a helpful list of questions and answers to some of the more frequently-encountered concerns. Perhaps most helpful of all was the UMD team’s visit to UVa partway through the project. Being able to meet and to speak face-to-face provided an invaluable opportunity not only to get feedback on our work, but to get a sense of the larger group behind the project, of the true scope of our team.
The lessons from this process were simple and striking: work together as much as possible, in person if you can and with frequent correspondence if you’re at a distance. There is no substitute for communication and interaction.
3. Be flexible. Schedules fluctuate. Schema change. Part of working with a large group of people means being able and willing to adjust your own schedule accordingly.
I’ll be the first to admit that this wasn’t always easy for me. My initial reaction to alterations to the schema was frustration, and my first response to technological gaffes, annoyance. Reworking my schedule to allow time to figure out how to install GitHub was a challenge. Actually installing it just hours before I had to teach the process to other people was an even greater one.
I quickly learned, however, that, inconvenient as such adjustments initially seemed, they often held a significant payoff in the end. Revising my encoded pages after schema changes, for example, allowed me the opportunity to go over each page again, making slight adjustments to the rest of my xml and reconsidering the decisions I had made about the document as a whole. The technical glitches that appeared in GitHub and Oxygen were time-consuming to solve, but they also taught me a great deal about set-up and troubleshooting that I would not otherwise have learned. Such information allowed me to be far more helpful to my team; the problems they encountered were, almost invariably, the same ones I had faced only hours before, so it was easy for me to remedy them.
I will be the first to admit that there were more than a few areas in which we could have improved. The structure of our project, for instance, was a work in progress from the beginning, as we worked to adapt UMD’s model to fit our course requirements. The demands of learning xml also kept us working relatively slowly, and had the project continued for a longer period of time, we would certainly have been able to encode a greater number of pages at a faster pace.
The spirit of the Villa Diodati, however, stayed with us. We saw it frequently on the pages of the manuscript we encoded, as when Percy Shelley revised Mary Shelley’s writing or Mary Shelley took notes on an envelope addressed by William Godwin. We saw it in the SGA schema, too, as input among the team at MITH led to the development of new tags or more nuanced markup. And we saw it in our team of encoders which, despite markup frustrations, technological failures, and a hundred miles of distance, managed to create a successful and fruitful collaboration.