Our "Techtual" Condition

A Tay [Bob] Brown [Ross] Perspective:

Git is to GitHub as a wandering Wordsworth is to a cloud: two deliberate and methodical memory banks capable of housing and tracking every alteration and transmission error for a work committed therein. Every computer has a point of access where the user assumes the role of administrator and the nuanced capabilities of the computer can be controlled. Often referred to as the terminal, users can manage all of their files and digital content right at the command line, and, with a distributed version control software downloaded, those files can be monitored by your computer and their versions tracked. Better yet, Git Bash—the command line access terminal with Git’s version control software enabled—communicates directly with GitHub, making backing up files in the cloud as simple as memorizing a few simple commands. So, what you have when you manage your files in this way is a web of interaction wherein all of the files—or witnesses, if you are feeling particularly textual—communicate with each other and update almost automatically to the most recent version while the outdated versions are stored for reference later in a digestible commit history. When I first heard about this, I immediately thought of McGann’s complicated webs of sociological interactions between texts, editors, type setters, friends, lovers, and the authors themselves, and I couldn't help but think that this work may lend itself to this type of software, perhaps even more so than the developer work it was designed for; and so the journey to total version control began.

The first step in this process was to open a new GitHub repository devoted to this project. GitHub repositories are free and public by default, their contents, thus, are also public unless you specifically select and pay for private repositories. This may instill trepidation in some creators and editors—the idea that anyone can view your repository and your files at any time—but in my case this was exactly what I was looking for. What I found was that I felt more confident than ever before in my ability to monitor and keep track of all of my work because I knew that at any moment I could refer to the commit history and know what I had done to alter my texts. Also, there is something empowering in being able to work with a computer on that level; to be able to tap into the "computer’s raw power" as Joris van Zundert puts it in his chapter, "Barely Beyond the Book?" (86).

Current group work models for digital humanities projects typically employ a computational specialist or developer to oversee the technical aspects of the project while a professional or researcher in the applicable humanities field oversees the curation of content to be represented digitally—these teams can be comprised of as few or as many members as seems necessary to achieve the goals of the project. Joris van Zundert contests this model of collaboration: "Once the work is done, the client and developer can go their separate ways, without having essentially influenced the methodologies on either side" (92). He describes this phenomenon as a “paradigmatic regression” or, in simplified terms, our tendency to only superficially affect the methods of our collaborators because of our reluctance to abandon familiar and tested methodologies (Zundert 85). He goes on to show how collaboration between textual scholars and developers can extend so far as an exchange in terminology:

The developers began to refer to concepts such as 'page', 'annotation', 'transcription'. The researchers grew accustomed to using words such as 'user', 'interface', 'architecture', as well as the vocabulary that is rather typical for the agile methodology used by developers…. (Zundert 91) While this transference of terminology between actors may seem to affect their lasting methodologies, it can be assumed that once the necessity to use this modified vocabulary fades the average person will simply revert back to the method that they are most familiar with.

The issue with this model is that the actors cannot fully conceptualize the work of the other and thus their communication is disrupted and the work made more difficult. Collaboration among developers often takes a much different form, actualized in cloud applications such as GitHub making for seamless distribution and management of files and code. It should come as no surprise why developers have mastered collaboration; they developed the software that manages the software they develop, and therefore have an experiential understanding of the inner workings of these environments. Just as a textual critic is fluent in reading the symbols that make up the critical apparatus, a developer is attuned to monitored collaboration in a version controlled environment. If concessions have to be made on one side or the other, I'll be the first to say the humanists need to set aside their pride and figure out GitHub. All disciplines should have equal sway over the digital technologies that are soon going to be our primary mode of transmitting our history.

I have a vision of a version-controlled human record, recorded by teams of actors who are experts in their fields and who feel completely at home on the command line, regardless of their training in software development—humanities scholars and humanists, more generally, making commits and forking versions without hesitation. It's an optimistic dream, but not entirely far-fetched. GitHub is already equipped to manage non-computational content and lends itself particularly well to textual versioning. It's going to take some courage on the part of the humanists to trust in their ability to understand the software, but there is no difference in the acuity of a developer and a humanist to memorize a list of commands.