University of South Carolina
Presented at the 2016 Conference on College Composition and Communication
Accompanying slides available at Google Slides
Git as Site for Distributed and Iterative Composition
One of the most popular and significant moves in composition studies over the past twenty years has been to expand the field's knowledge of composing as a iterative and collaborative activity. This move has often occurred in conjunction with an expansion of the definition of "composing" beyond "writing," leading to robust theories and pedagogies relating to networked and multimodal composition (with far too many scholars to cite concisely here).
However, as part of these efforts, we have not spent as much time as we might need to in regards to the iterative and collaborative action that our composing performs, especially in digital environments and with digital tools. (When I say iterative here I mean looking at each version of a text as a separate iteration, rather than distinguishing only "major milestone" versions of texts, e.g. student first drafts and final drafts.) The vast majority of digital composing activities employed by software and content developers, building and framing contexts for "end-users," remains inadequately defined or explored by scholars interested in rhetorical invention and practices of composition, although there are certainly those who strive toward this goal in intriguing and valuable ways.
Of the available digital technologies that might illuminate for us how iterative and collaborative composing can and does operate, version control software may be the most useful and flexible. Version control is a means of tracking changes made to a file—usually, but not limited to, "raw text"—over time. For example, Google Docs' revision history tool is a potentially familiar example of version control (Google, 2016). While there have been many version control systems to emerge for amateur, professional, and enterprise use, none has been quite as popular in its uptake as git, a command-line program that provides users with a flexible means of collaborating in a distributed and iterative fashion.
In this presentation, I examine how git works effectively not only for programmers but also for composers engaged in prominent and emergent digital genres and contexts, where the mode of writing is complemented by procedure in the creation of texts and the anticipation of future response to and engagement with those texts. To that end, I will look at git itself as well as an example case and activity system of collaborative composition using git.
Digital Composition as Action
Composing as action often gets overlooked by approaches to composition as semi-instrumental use for some other purpose (that is, it serves as the inducement for other, future action but is not always perceived itself as action). Complicating matters further is the distinction between composition of the digital artifact and composition-anticipation of any subsequent engagement of/with that artifact. That is, there are effectively two fundamentally different kinds of meaning-making occurring as one composes.
A consideration of composing as action, beyond the scope of understanding invention as rhetorical practice for delayed performance, allows us to see how one or more rhetors continually negotiate with and persuade themselves, collaborators, and other actors to develop some meaningful argument (in whatever form). That development is a complex ecological system and vector of activity that, in many cases, we "black-box" in an effort to look at how that activity led to other action(s).
What a vector-centric look at composing-as-action offers us, then, is a clearer understanding of action less as moments of interest than as a change occurring over time, with opportunities to see folding and unfolding trajectories of potential realization as various decisions are considered and made—a kind of Zeno's arrow, so to speak.
Version Control and Iterative Composition
Version control systems, then, facilitate the viewing of changes to digital artifacts over time so that one might either examine any individual iteration (to study it as a reflection of the decisions made up to and at that point) or the aggregation of iterations that plot out said artifacts' vector. For collaborative works, version control systems allow for the simultaneous examination of multiple vectors, as different individual contributors may compose and study different versions of the "same" text at different speeds or schedules. These systems of networked collaboration reflect what Spinuzzi (2003) has described as "complex activity system[s]" of collaborators, artifacts, genre ecologies, domain knowledge, divisions of labor, and objectives (pp. 104-105).
Further, version control systems enable the development of independent lines of invention and inquiry by each collaborator; while an artifact may be "merged" back together at various intervals--if so desired by said collaborators--it may also spin out into multiple forking vectors that are not ultimately expected to perform in similar manners or for similar goals in comparison to the others. These divergent, and sometimes conflicting, vectors emphasize the procedural qualities of collaborative composition, as involved contributors must undertake constrained approaches to deliberation and negotiation of various branches' integration into others. These approaches demand implicit (if not explicit) awareness of persuasive strategies that facilitate particular procedural logics (for more, see Brock & Shepherd, forthcoming).
Where version control systems have been taken up most broadly is in the field of software development, as the work for collaborative projects can be easily delegated among members, tested, and reintegrated into the "main" program as desired--or, as noted above, split into distinct forks due to differing opinion, or revised purpose, or some other reason entirely. The semi-decentralized nature of version control systems facilitates this sort of vacillation; the files have a traceable history but are only restricted or unavailable in terms of further revision within the forks or branches belonging to or used by individual contributors. In other words, such artifacts resist--in a fundamental, mechanical sense--stasis.
Of the various version control systems currently in use, git may be the most popular. Its easy implementation into large-scale collaborative systems and websites (e.g., GitHub, which boasts hosting over seventeen million software projects as of Nov. 2014) makes it a particularly useful case to explore regarding the collaborative and iterative potential for digital composition.
Git exists as a command-line program that is incredibly powerful and versatile but, because of its command-line nature, may feel alien or uncomfortable for many users to work with when there are GUI programs that perform somewhat similarly even if not so well for the sake of distributed and iterative composing.
In particular, git establishes text artifacts as points along any number of potential vectors, changes to (or perhaps "realizations of") those vectors, and intersections across multiple contributors' version-iterations of those vectors and their points. Unlike a program like Google Docs, git does not force other contributors to engage a file modified by someone else until those other contributors specifically request the different file versions to be merged. In other words, every contributor has equal access to control the development vectors of his or her texts.
Of course, this capability isn't particularly obvious visually—git's CLI obscures much of this ability unless one is functionally literate in the program's output. Fortunately for many collaborators (and students of rhetoric, composition, and software), a number of websites have been developed to serve as more navigable/accessible interfaces for the program.
Git as Facilitator of Distributed Composing
Git's uptake has been buoyed in large part by the popularity of the websites GitHub and Bitbucket, which host millions of projects for nearly as many users. These sites serve as nexuses where individual projects can be explored, forked, merged, and—in an interesting demonstration of social networking—commented on (and in some cases rated or otherwise evaluated by users).
If git is potentially off-putting as an unfamiliar tool in an unfriendly interface, sites like GitHub work to mitigate those feelings of confusion or frustration (not that they're always successful in doing so, of course). Further, the sites provide more accessible means of navigating, comparing, contributing, and otherwise engaging in the acts of Internet-based, and potentially large-scale, distributed composing. As a result, I turn here to examine how these kinds of composing are facilitated, negotiated, perceived, and further developed by the use of git and, in many cases, by sites like GitHub as further interfaces for the program.
Specifically, I look at a project undertaken not to develop software but to compose a textbook on mathematic type theory. It was developed using git to illuminate not only what the composing activities were in regards to each but also what git's role was in influencing those activities.
The Case of the Homotopy Type Theory Textbook
In 2013, mathematics professor Andrej Bauer began collaborating with 39 mathematician colleagues to develop, in/with git and on GitHub, a textbook on Homotopy Type Theory (HoTT) that various populations of students (well-versed and otherwise about mathematics and type theory) might find useful. Even after its official publication, the collaborators have continued to release iterative updates to the text, sometimes to correct errors and at other times, based on feedback from readers, to provide more useful examples or explanations of particular concepts or applications. Further, a "second edition" project has forked out of the original project in order to take a significantly revised version of the textbook in directions other than its initial authors may have intended or in which they were interested.
The HoTT textbook collaboration is a complex activity system, and its complexity is dramatically impacted by the employment of git for composing purposes. Specifically, the actions of each contributor are complicated by the actions intertwining with those of each other contributor, including:
- creating new files
- drafting text for one or more files (in each contributor's text editor of choice)
- revising or editing existing text
- incorporating (merging) others' contributions into his or her version of the project
- requesting others to merge his or her contributions to their versions of the project
Sometimes this intertwining occurs in complementary fashion (such as when two or more contributors develop exercises for a chapter, with each example reflecting the goals of the chapter without making the other exercises redundant). Sometimes it does not, such as when multiple contributors independently work on the same files and must subsequently untangle the optimal sequence of merges to generate the desired result files (in whatever compromised sense that might be for one or more of the involved contributors).
The HoTT Textbook as Complex Activity System
Bauer and his colleagues participated as members of a complex activity system during their development of the HoTT textbook, working with one another to create a solid resource for teaching HoTT to mathematics students but, just as importantly, to engage in the powerful rhetorical action of collaborative composition and disciplinary negotiation. At numerous moments, one or more contributor would examine an iteration of the textbook, compare anticipated audience responses to vectors of author contributions, adjusting as interested (such as moving closer toward a desired response or elaborating on a previously underemphasized section of text.
Their iterative approach to collaborative composition was complemented by the forum resource offered by GitHub; as new versions of the book were introduced by its contributors, other existing or potential collaborators could influence continued work--with interested readers effectively serving as participatory designers of the document, even if their "contributions" are not formally recognized. For example, Shulman et al. (2014) negotiated how "identity types" were introduced in the textbook, as initial releases provided several examples of identity types without explanation of the concept. As various options were explored, with some introductions drafted, the involved contributors ultimately decided to provide some concise explanation but they rejected all of the drafts proposed in that discussion thread (as being either trivial or reductive or otherwise unhelpful).
Throughout the continuing life of this project, the forty contributors have developed into a community of collaborators who gained access to one another's input, ethic, and writing style in ways that may not have been possible in other environments or with alternative tools. As Bauer noted,
[T]he spirit of collaboration that pervaded our group at the Institute for Advanced Study was truly amazing. We did not fragment. We talked, shared ideas, explained things to each other, and completely forgot who did what (so much in fact that we had to put some effort into reconstruction of history lest it be forgotten forever).
According to Bauer, none of the authors had ever used git before, but their concerns about large-scale collaboration were valid: there was a need to make sure changes could be made by any author, that such changes could be identified easily and reverted if necessary (e.g., if any errors were included in a new version of a file), and that authors could work at a pace that did not demand close attention to synchronous editing (such as the kind of automatically-pushed updates to files that Google Docs provides to collaborators).
The complex HoTT system was comprised of diverse agents, motives, tools, and modes of composition in order to publish the desired textbook. To achieve this goal, the collaborators created meaning iteratively through writing, procedure, and image (mathematical figures) across numerous digital platforms.
So how is this case helpful for compositionists to consider further study (and/or employment) of git? First, we can attend to moments of familiarity that might prove fruitful for understanding distributed, iterative composing with tools like git--such as the means by which the HoTT collaborators performed peer review in determining what contributions were worth merging, rejecting, or modifying further. Second, we can attend to moments of unfamiliarity, such as comparing the interfaces for git and GitHub with those of MS Word or Google Docs or other popular programs for textual composition.
More generally, we have an opportunity to explore iteration in composition in a more granular fashion. What might a closer look at small-scale, as well as large-scale, changes mean for helping us understand better collaborative composing processes? How do models of composing collaboratively reflect, if at all, the patterns displayed by individual and group composers of projects like the HoTT textbook?
Bauer, A. (2013). The HoTT book. Mathematics and computation. Available from http://math.andrej.com/2013/06/20/the-hott-book/
Brock, K., & Shepherd, D. (Forthcoming.) Understanding how algorithms work persuasively through the procedural enthymeme. Computers and Composition.
Google. (2016). See the history of changes made to a file. Docs editors help. Available from https://support.google.com/docs/answer/190843?hl=en
Shulman, M., et al. (2014). Use and introduction of identity types. GitHub. Retrieved from https://github.com/HoTT/book/issues/730
Spinuzzi, C. (2003). Compound mediation in software development: Using genre ecologies to study textual artifacts. In C. Bazerman & D.R. Russell (Eds.), Writing selves/writing societies: Research from activity perspectives (pp. 97-124). Fort Collins: Colorado State University Press. Retrieved from http://wac.colostate.edu/books/selves_societies/
Wanstrath, C. (2014). The story behind the new GitHub Enterprise. GitHub. Retrieved from https://github.com/blog/1919-the-story-behind-the-new-github-enterprise