Chapter 7

Making the RA Matter: Pedagogy, Interface, and Practices

Janelle Jenstad and Joseph Takeda

For many years at The Map of Early Modern London (MoEML, a Canada-based literary mapping project), our project mantra has been “we are the makers of manners.” It began in a teachable moment, when a research assistant (RA) questioned our non-compliance with MLA citation guidelines. Jenstad spontaneously quoted “We are the makers of manners” from the final scene of Shakespeare’s Henry V, where Henry tells his manners-conscious bride-to-be that they are not to be “confined within . . . a country’s fashion.”[1] In other words, Henry and Katherine, by breaking the old rules, make the new fashions of the country; others will follow their lead. This potentially presumptuous mantra has allowed the project director (Jenstad) to deconstruct the authority of the MLA and other academic rulebooks so that our project could be innovative in matters of citation, credit, and collaboration. Perhaps inevitably, the remaking of academic manners led to the remaking of project hierarchies. If the project’s leaders could challenge the authority of even the venerable MLA Handbook, then perhaps the RAs could challenge the project directors and lead programmer.[2] Our project ideal has thus become our training ideal, with the consequence that MoEML RAs are themselves “makers of manners.” Just as our project challenges disciplinary authorities, the RAs challenge the directors’ and programmers’ authority in ways that change the “manners” of our project. They become full collaborators, complementing and sometimes superseding the project leaders’ expertise. They take responsibility for key areas of the project, identify opportunities, propose solutions, set the standards, and document project practices. In this process, we make the RA matter.

“We” is the key word in that last sentence.[3] Jenstad does not build the digital humanist, any more than she alone is responsible for building MoEML. This chapter is co-authored by Jenstad (a tenured faculty member) and Takeda (an undergraduate student who began as an RA and has since become MoEML’s first Junior Programmer), because making the RA matter is a collaborative venture. The RA has a role in her[4] own “becoming” or “sense-making” (Chachra).[5] In keeping with MoEML’s training obligations as a federally funded project, the director provides training and learning opportunities. In order that the project’s goals are met, the director requires the RAs to learn from the training; in fact, a precondition of hiring is “teachability,” an expectation we formalize in our RA contract.[6] However, “making” requires not just “the will to know” but also “the will to become” (hooks 19). This distinction comes from bell hooks’s vision of liberatory pedagogy in Teaching to Transgress (1994). She suggests that students want “knowledge that is meaningful” and connected to their “overall life experiences,” with the important caveat that students “will not always accept our [teachers’] guidance” (19). In this model of teaching, students “assume responsibility for their own choices” (19). Is it possible to implement a liberatory pedagogy (a model developed for the classroom) in a project environment where the granting agency demands benchmarks, fiscal accountability, and final reports? We argue that it is not only possible but also ultimately beneficial to the project to create a space for RAs to challenge the project leaders and take responsibility for their choices.

Our contribution to this volume articulates the potential for a liberatory model of training and describes the process of making[7] the RA. Our argument takes place in three movements. First, we address MoEML’s training history, arguing that MoEML, like any other institution, had and still has the potential to be hierarchical, inverted, flat, or transgressive. Second, we reflect on what it means to “make” the RA. We mobilize the recent work in interface theory, namely Wendy Chun’s (2011) historicization of human interfaces and Johanna Drucker’s (2013) work on interfaces as border zones, to argue that positioning the RA as an interface allows us to realize hooks’s transgressive model of liberatory pedagogy. Third, we look at the manners — the practices, habits of mind, and guiding principles — that are required and called into being by this new model of training. In this chapter we seek not to prescribe another set of rules for building digital humanities (DH) project teams or write another set of learning outcomes for granting agencies, but rather to emphasize the pedagogical potential of allowing the team to make itself in ways that work for the project and personnel.

Institutional History

What is MoEML? The quick answer is that it is a grant-funded, open-access suite of digital resources and tools for the study of Shakespeare’s London. The longer answer positions us somewhere between a DH center, maker lab, program, and classroom at the University of Victoria (UVic); we are not any one of those things, but we have certain practices and values in common with each of those models. MoEML is not a center with its own physical space, but we do book work stations in the shared space of the Humanities Computing and Media Centre (HCMC), where we rub shoulders and refine ideas with personnel from other DH projects.[8] Other places we gather include Jenstad’s departmental office, a project office in the same building, the Special Collections and University Archives classroom, the computer teaching labs, and occasionally the campus pub. We conduct much of our business via virtual workspaces: e-mail, Google Drive, a Subversion repository, GitHub, and web-based project management tools (Asana). MoEML is not a makerspace, at least insofar as we are not engaged in physical computing or fabrication. However, our work toggles between the digital and the material on a daily basis: our new map of London was made partly with paper, tape, and artists’ pens; our site menus were first built with yellow sticky notes on long sheets of Kraft paper; rare books sit beside our mouse pads. We have made a number of digital things: a map interface, a gazetteer, mapping tools, and a CodeSharing tool. And we have remade, or remediated, a number of rare books and maps by digitizing, transcribing, and encoding them. Nor is MoEML a program; we operate in some ways like the Praxis Program,[9] but we tend to hire undergraduate and MA students rather than PhD students, and our students join an ongoing project rather than collaboratively conceiving and completing the new project that the Praxis program requires. Although it is a grant-funded project hosted on UVic servers, it is no longer a single-researcher-directed project; we now have a leadership team and are answerable to our editorial board, contributors, peer reviewers, and pedagogical partners. Despite our training mandate, MoEML is not a classroom, either. We do not offer for-credit courses, although we often provide opportunities for students undertaking research scholarships,[10] theses, DHUM or DHSI projects,[11] or work placements in Professional Communication. Even now, as a peer-reviewed, indexed project, we honor our classroom roots in our current pedagogical partnerships.[12] In short, we inhabit multiple campus spaces, retain the do-it-yourself (DIY) ethos of making, follow the ethics of the Praxis program, and find ourselves teaching others and each other all the time.

Given that our project history and current structure are both well documented (see Jenstad, “Restoring Place to the Digital Archive”; Jenstad, “Using Early Modern Maps in Literary Studies”; Jenstad, “History of MoEML”), we focus here on our identity as a pedagogical “institution” with a training mandate derived from the Social Sciences and Humanities Research Council (SSHRC), the federal funding agency that has supported MoEML through two research grants. A key part of any SSHRC application is the “Research Training Plan.” According to SSHRC’s “Guidelines for Effective Research Training,” the plan must describe how the supervisor or grant applicant will train students and build their competencies so that students acquire “valuable skills” and gain “new perspectives and knowledge.” Ultimately, SSHRC thinks of the RA as a product of the academic world for the benefit of the non-academic world: such students will carry their humanities skills into post-academic life and “make strong contributions in Canada and globally.”

The SSHRC model presupposes that grant-funded projects inherit the structures of traditional learning institutions. Cathy N. Davidson and David Theo Goldberg (2010) note that “[i]n conventional learning institutions, the lines of authorship and authority are clearly delineated, and the place of teacher, student, and technology are known” (7). Our first “RA Contract,” based on Jenstad’s 2011 “Research Training Plan,” expected that, by the end of their tenure, RAs should have “internalized MoEML’s standards” after gaining “more autonomy in individual tasks.” Following SSHRC’s language, the contract sets out an apprenticeship model anticipating that the student will gain mastery of trade secrets in the process of making increasingly complex digital things under the direction of a master-practitioner (Jenstad, “Training and Work Practices Contract”). The contract’s transferable learning outcomes describe what skills the RA will have and the tasks the RA will be able to do by the end of the MoEML work period. The verbs — deploy, digest, write, understand, troubleshoot, document, record, work with — lend themselves to repetition on the students’ resumes; those learning outcomes also align with one or more of the tasks required for MoEML to achieve its goals, suggesting there is a close relationship between the making of the project and the making of the RA’s competencies. The RA makes the project according to the supervisor’s specifications; simultaneously, the supervisor, fulfilling the funding agency’s mandate, makes the RA. Jenstad has always seen project leadership as an extension of her classroom-based pedagogical practice. MoEML team members are accustomed to regular pauses in the work where we seize teachable moments. Jenstad and the other project leaders (Kim McLean-Fiander and Martin Holmes) regularly take the time to explain the ideological and scholarly issues that drive the project, as well as to share their knowledge of historical, technological, bibliographical, and cultural matters.

But, as Davidson and Goldberg suggest, with “digital learning, these conventional modes of authority break down” (7, our emphasis). Jenstad has long appreciated the way the project inverts the roles of teacher and student. The teachable moments have never been uni-directional at MoEML. Since 1999, when MoEML began as a project for three students who needed a “client” (i.e., Jenstad) and a challenge (“Well, I’ve got this old map . . .”) in a second-year “Writing Hypertext” course at the University of Windsor, MoEML has often been indebted to student initiative and expertise. Initially, Jenstad, who did not train as a digital humanist, relied on students to teach her. She paid students from that “Writing Hypertext” course to teach her HTML; other students later tutored her in the Text Encoding Initiative (TEI), Extensible Markup Language (XML), and Extensible Stylesheet Language Transformations (XSLT). As work-study RAs, students working for academic credit, and grant-funded RAs came and went, the project developed a pattern whereby Jenstad taught each new team member everything she knew; the RA’s final responsibility was to teach Jenstad everything she had learned on the job. Eventually, the team became big enough to warrant formal training sessions that covered analytical bibliography, text encoding, research hygiene, and project praxis; by staggering RAs’ terms, Jenstad was able to delegate much of the training to outgoing and experienced RAs. Role-switching helps everyone learn, but the inversion of roles ultimately reifies the one-way model of training. This carnivalesque inversion of teacher and student implies that someone must always be the teacher and someone else the student and ultimately reinforces the hierarchical nature of traditional training.

As we rethink our training plan for another SSHRC application, we have the opportunity to reflect on and revise the model Jenstad derived in 2011 from the rhetoric of SSHRC. Jenstad did not articulate in that initial grant application what she already knew to be true: that the project director is also a trainee and, furthermore, that inviting the RAs to be teachers is a key component of their “training.” During the lifetime of that grant (2012–16), MoEML developed its model of student training still further and came to believe that the hierarchical and occasionally inverted model of teacher and student is not the best model for the project, the students, or the project leaders. In our 2015 grant application, we articulated more clearly that our RAs are “contributors with a stake in the project.” In fact, outgoing RAs Takeda and Tye Landels wrote that section of the grant. When asked to “copyedit” what Jenstad had drafted, they argued that they were the people best qualified to articulate what and how MoEML RAs learn during their tenure with the project. The collaborative work on the grant is itself a sign of how a hierarchical model can give way to a more dynamic team model in which diversely talented people challenge and complement each other daily. MoEML is in fact more like the “mobilizing network” that Davidson and Goldberg propose as the future of learning institutions (127). Instead of being hierarchical, MoEML tries to “aggregate, coordinate, disperse, balance, and adjudicate complex flows of resources” (129). McKenzie Wark (2013) observes that “collaborative labor is an and-also” kind of play (our emphasis). We try to avoid “thinking that X is by origins higher in rank than Y.” Each MoEML team member brings unique qualifications and natural talents to the project; during the course of the work, each team member develops particular domain expertise and even a sense of ownership over aspects of the project, thereby dispersing and balancing resources. We need both X and Y to move their domains forward independently. We develop new domains when X also helps Y and vice versa.

Our shift towards a liberatory or transgressive model of training occurred in step with other new models, especially those articulated by the Scholars’ Lab Charter and the Collaborators’ Bill of Rights. The Scholars’ Lab (SLab) is a collaborative digital scholarship center and makerspace that fosters teaching, learning, and mentoring through consultation with other projects. The SLab Charter appeals to the pathos of working for a digital project by focusing on the “whole person”; at SLab, where they “build up people, not tools,” you are “more than your job, your field, your role.” The Charter does not spell out what collaborators might become; rather, it values collaborators’ agency and encourages everyone “to develop new ideas and grow as scholars and practitioners” (The Scholars’ Lab). Although MoEML is a project, not a place for supporting projects, we can learn from SLab’s focus on the whole person. The collaboratively written Collaborators’ Bill of Rights (CBR)[13] articulates the ethical problems of and solutions for acknowledging collaboration. Formed as a response to the single-author-credit paradigm of the humanities wherein the first writer is often the only individual acknowledged, the CBR argues for proper accreditation of labor within DH projects: credit must be given where credit is due, collaborators should be “empowered to take credit for their work,” and attribution for labor should be listed publicly on the project website. Like many other projects, MoEML has adopted the CBR’s principles of crediting all contributors and recognizing their right to articulate the nature of their contributions.

While these documents articulate exemplary models of collaboration between graduate students, postdocs, early career scholars, and senior faculty, they do not provide guidance for collaborations with the undergraduate students who comprise the majority of MoEML’s team. The Student Collaborators’ Bill of Rights (SCBR) extends the CBR by acknowledging the centrality of undergraduate contributions to many digital projects. The SCBR spells out the numerous ways a student may contribute to a digital project: as a hired research assistant, via a directed reading or capstone project, or through an assignment within a course structure. Students must be acknowledged for all “non-mechanical” labor that furthers the site in some way, whether financially compensated or not. The SCBR provides an “additional safeguard for students” by recognizing the hierarchies within DH projects and institutions (Di Pressi et al.). Undergraduate students find themselves working with graduate students, early career scholars, programmers, and tenured faculty members. The SCBR does not fully address the complexities of acknowledging content created by students as students (for credit), by students as employees (for remuneration), or by and with undergraduate students at the intersection of their roles as student, advisee, expert, and employee. However, from the SCBR, we learn to acknowledge the hierarchies that pertain on projects where contributors occupy multiple roles in the larger institution.

Where Making Happens: The RA as Interface

How do we create the preconditions for the RA to mobilize the will to become? We believe that the way to create a liberatory training plan is to position the RA as the interface. Given the history of interfaces, our desire to position the RA as interface could sound regressive. Interfaces have not traditionally been liberatory. Human interfaces, like the “women of the ENIAC,” have been invisible, underpaid, and unacknowledged. Yet recent work on these early human interfaces between machines and output shows that they “did not simply operate the machine, they helped shape it and make it functional” (Chun 31). We do not want students to be the new (derogatorily named) “ENIAC girls” — essential but unacknowledged. Our strategy is to invite the RA to take on and adapt some of the director’s interface functions.

Normally, the director is the interface in that she is the “place of interaction between two systems,”[14] the two systems being a scholarly-professional system on the one hand, and a pedagogical system on the other. In the SSHRC model, the director is the hub of the project, where she serves as the interface between the RA and the research problems. In order to solve the research problems or achieve the agenda that she has set out in the grant application, the director directs and bridges the different personnel on the project: the co-applicants, the programmers, the contributors, and the RAs. The RAs accomplish specific tasks that allow the director to achieve her agenda and address the research questions. In performing those tasks, the RAs achieve certain learning outcomes that serve their own professional development. Eventually, the RA is the vehicle by which competencies and skills are transferred “to a variety of settings” outside academia.

In that model, the RAs might function as the historically regressive kind of interface that invisibly enables “techno-human mediations” (Drucker 213). Transforming data in the service of larger research questions to which they may not be privy, RAs could be the “invisible hands” that transcribe, collate, transmediate, encode, or correct. This type of work might easily be categorized as the “mechanical” labor that does not need to be acknowledged even under the generous terms of the SCBR. SSHRC’s training mandate does not require acknowledgment of the RAs’ labor: their remuneration is fiscal and intellectual. In our experience, however, even so-called “mechanical” labor demands critical decisions and domain knowledge. Not only does MoEML leave a trace on the RA, but the RA leaves a critical trace on the project. In keeping with the SCBR, we need to render that trace visible through credits and acknowledgment. Such a practice ensures that the RA is not an invisible mediator between the digital data and the project director. However, it does not liberate RAs or, to borrow from hooks, invite them to become. Giving credit does not, by itself, necessitate the transgression of traditional project hierarchies.

MoEML has a long history of positioning RAs between domains. Our preferred training mechanism is, in fact, to position the RA, rather than the project leaders, as the “place of interaction between systems.” We can draw on various meanings of interface to theorize the roles of the MoEML RA. The RA can be useful as a mediator between the technologist and the humanist. Jenstad has often needed RAs with computer training to “translate” between her and the project’s programmers; in that work, the RA functions as a kind of HPI, a humanist-programmer interface or what Drucker deems a “place of interaction between two systems” (213). But how do we ensure that the RA is not simply a membrane between systems? We want the RA to inhabit Drucker’s “space of individual and collective formation” (217). At MoEML, we move the director out of the way and make the RA the interface between the project and the research questions. That place is not only a “border zone between cultural systems, with all the complexity and emergent relations that suggests” (216) but also an “autonomous zone . . . of activity” (Galloway vii).

When RAs as human interfaces have agency and autonomy, they “are not simply objects or boundary points” (vii). The RA is an agent “in constant formation” (Drucker 216), inhabiting a zone where new skillsets and relationships emerge. For example, Takeda came to MoEML as an English major with an interest in computer science, making him a logical candidate for liaising with lead programmer Martin Holmes. Takeda’s expertise in the site infrastructure and development code is now far superior to Jenstad’s, and on occasion we have experienced the hierarchical inversion of Takeda assuming the role of teacher. But what is really valuable is the labor process that invites Takeda to “map the thinking from one labor process onto another experimentally” (Wark). He wields both the programmer’s hammer and the humanist’s idea of a hammer; he can see both the nail and the idea of the nail at the same time. Takeda’s position as interface between systems invited him to become something new: a humanist programmer or programming humanist. By occupying that ecological border zone between humanities and programming, Takeda willed himself to become our junior programmer, a role he chose to inhabit and a title he claimed for himself in the project’s credits.

Making New Manners

What does it mean in practice to position the RA as interface? We are not suggesting that a liberatory model of training simply invites RAs to define new roles for themselves. On the contrary, there are a number of practices, habits of mind, and guiding principles that are required and called into being by this new model of training.

Recognizing that a truly flat team structure is probably impossible in a hierarchically organized institution, we strive in our small corner of the institution to keep our team dynamic and flexible; the institutional gaps between professor and student are thereby “compressed” so that we can achieve what we might call a “flatter” team structure. For example, anyone can add items to the agenda for team meetings. Agenda items are solicited by the project manager, and the final list is given out at the team meeting; Jenstad does not pre-approve the agenda, and her items have no more or less weight than those of any other team member. Team members will often prepare presentations to contextualize a problem or justify a recommendation. Using the task management software, anyone can assign tasks to anyone else, and everyone can track all the tasks in our shared workspace. Occasionally, Jenstad will exercise “directorial privilege” in a self-conscious way, invoking her experience and longer view of the big picture. However, anyone on the team can, at any time, call us back to our guiding principles (such as “Tell the truth in encoding”), and everyone is free to disagree and make a case for a different way of proceeding. The flatter model invites the transgressive challenges that often push the project where it needs to go next. The transgressive model is not simply a “world-upside-down” model where we occasionally reverse the hierarchy; on the contrary, it disperses and localizes authority by recognizing that the person best qualified to make a specific judgment call is not necessarily the project director.

In a flatter structure, individuals’ knowledge of the project can be recognized as a domain expertise. We actually see Jenstad’s “big-picture thinking,” grant-writing skills, and project memory as particular kinds of domain expertise and not as overarching expertise. While Jenstad has large objectives, she invites team members to gravitate toward the work that attends to their own research interests and skills. The RA can choose tasks out of the pool of tasks, create new tasks in keeping with larger project goals, and suggest new ways of achieving those goals. A key part of team culture is mutual recognition of each other’s nascent and maturing domains. We call regularly on each other’s experience and specialized knowledge, saying things like “Tye is our Praxis expert,” “Ask Joey to show you how to make tables,” and “Katie is tackling the mayoral shows.” Our project culture therefore “mobilizes collective activity and activates inspiring and productive resources and social relations” in the way that Davidson and Goldberg suggest (138). Across our distinct domains, we take ownership for our own work, but we also feel a sense of shared ownership for the project. Inclusive language is a natural extension of our working practices: our working pronouns are “we,” “our,” and “us.”

The overarching principle of our project is “Tell the Truth.” The phrase comes from our programmer, Martin Holmes, who insists at every turn that our encoding of texts be truthful. Markup must be faithful to the text we are encoding and to our own project guidelines. The concept has percolated through other aspects of the project. We show our XML — four versions of our XML, in fact[15] — to make our treatment of the text fully visible to (and reusable by) other scholars. In doing so, we become accountable for every change to the text and every comment we leave in the XML file. Holmes developed the aforementioned CodeSharing tool and an Application Programming Interface (API) that allows users to search every element, attribute, and value used in our project.[16] Having committed to the principle of telling the truth about our encoding, we have done all our work in the knowledge that every aspect of it is public-facing. All of the project documentation and encoding instructions are captured in the Praxis section of our site, which is itself indexed in multiple ways.[17]

Encoding our Practices

We are now guided by the imperative to tell the truth about who did what when on our project, an imperative that has had radical implications for how we acknowledge collaborative work and student work in particular. Like Davidson and Goldberg, we have observed that “the more collaborative the project, the more we must think about individual credit” (9). Our encoding practices are meant to encode our practices as a team and recognize individuals. The metadata for each document (captured in the <teiHeader>) includes multiple responsibility statements, each captured inside the <respStmt> element, which “supplies a statement of responsibility for the intellectual content of a text, edition, . . . where the specialized elements for authors, editors, etc. do not suffice or do not apply” (TEI Consortium). Any contributor can have more than one responsibility statement, which allows us to describe various roles that any one person might have played at various points with respect to a particular document. Consider one of Sarah Milligan’s responsibility statements in the metadata for our forthcoming edition of John Stow’s 1598 Survey of London:

The role is described in the <resp> element, which uses the @ref attribute to point to MoEML’s taxonomy of responsibilities.[18] The <date> element allows us to map the period over which the work was performed. These <respStmt> elements are rendered as credits that appear on the left-hand side of each MoEML document. In keeping with the SCBR, we invite RAs to characterize their contribution precisely in their own words. The content of the <resp> element is a free-text field, which allows contributors to customize the description of their role(s). Milligan corrected the original TEI-XML in the transcription of Stow’s Survey that we obtained from the Early English Books Online Text Creation Partnership (EEBO-TCP). While the standard code “mrk” ensures that Milligan is listed with all the other markup editors who have contributed to MoEML, her self-description as “Date, Forme Work, and Foreign Words Encoder” captures the precise nature of her work.

To tell the full truth about our project, we would have to give credit even to so-called “mechanical labor.” In fact, we believe that very little labor is actually purely mechanical; therefore, we have developed a taxonomy to describe the many ways in which RAs contribute to the project. In order to expand our vocabulary beyond the ubiquitous and limiting “author” and “editor” categories, we turned to the marcRelators used by the Library of Congress (LoC) cataloguing system to express “the relationship between a name and a resource . . . in bibliographic records.” From this list, we have adopted and adapted many roles, including some that are often considered too “mechanical” to be acknowledged. For example, we give credit to the proofreader of a document. MoEML uses the LoC marcRelator “pfr” “to designate a contributor who checks a transcription against an original document, or a person who corrects formatting and typographical errors in a born-digital article.” We also credit the person who proofreads the TEI tagging (in MoEML terminology, the “markup editor”) in a unique <respStmt>. The 37 named roles that we credit include annotator, conceptor, consultant, data manager, researcher, and transcriber. We have supplemented the LoC marcRelators with our own molRelators, which include copy editor, toponymist, vetter, cross-vetter, Cascading Style Sheets (CSS) editor, and guest editor. We have even corresponded with the LoC and successfully suggested new roles for their list of marcRelators.

These roles are not wedded to the particular RA or contributor in their entry in MoEML’s personography. We hired Milligan as a novice encoder, but her role changed considerably over her two years with MoEML. She now works as the Publishing Manager for British History Online but continues to contribute to MoEML as a research associate. We understand that people inhabit different roles at different times. In keeping with the SLab Charter, we see the person, not the role, as paramount. The granularity and multiplicity of the responsibility statements allow us to capture the person’s work in great detail without identifying the person with any one of those roles or limiting the RA to the nebulous identity of “RA.” All of these roles are linked to the contributor’s biography page, which offers a curated narrative and bio-bibliographical note about the person as well as a dynamically generated list of all the person’s contributions and roles.

Remaking Practice

Our most innovative work comes about when we aggregate and coordinate our resources and expertise. In our praxis of telling the truth, we often find ourselves challenging established standards, thus asking new sets of research questions. One such instance is MoEML’s ongoing engagement with historical dates. MoEML’s temporal scope puts it in the period of maximum calendar confusion for England, which did not adopt the Gregorian calendar until 1752, nearly two centuries after most other European countries. In the process of encoding Stow’s list of regnal years in the 1598 Survey of London, Milligan had to determine best practices for parsing and representing historical dates. Due to the complexities of early modern dating and the conversion from the Julian calendar to the proleptic Gregorian, historians have come to accept early modern dates as an insoluble problem of the field. But Milligan came to this problem using MoEML’s principle of honesty and consulted with Jenstad and Holmes to find a way to encode Julian dates truthfully.[19]

We believe the solution spurred by Milligan’s research and questioning, crafted by Jenstad and Holmes, and documented by another RA, Tye Landels, came into being through positioning the RA as interface. Milligan developed the research question and approached the various project personnel with complementary domain expertise. MoEML’s initial solution for encoding dates remained in use for two years but was recently questioned by Takeda. He came across a new problem with early modern calendars during a directed reading course on the weekly and yearly publications of the London Bills of Mortality. Takeda discovered that Milligan, Jenstad, and Holmes’s previous solution was not precise enough to record the various idiosyncratic scholarly attempts to regularize dates.[20] Just as Milligan had done some years prior, Takeda approached Holmes in hopes of finding a solution at the level of tagging; Takeda and Holmes then consulted with Landels and the three of them met, discussed, deliberated, and corresponded until they achieved consensus on a new practice for encoding and processing dates. They then approached Jenstad and the rest of the MoEML team with their recommendations; in this case, Jenstad was the last person to know of both the problem and Holmes, Takeda, and Landels’s solution. At the time of writing this present chapter, Takeda and Holmes are co-writing new code to handle a variety of dates in use in the early modern period while Landels crafts the rendering schemes and the explanatory Praxis documentation.

We discuss our long struggle with historical dates to show the effects of positioning the RA as interface. Indeed, forging the liberatory space for the RA to express their will to become has lasting consequences; acknowledging the RA’s autonomy betters not just the project and the RA’s experience but also the scholarship produced. Milligan’s project of recording regnal dates, which began as mechanical labor — transcribing the dates as recorded in Cheney, Holinshed, and Stow — grew to become an important research question that has the potential to rewrite the scholarly protocols for recording and regularizing early modern dates.

Conclusion

MoEML RAs now leave the project having rewritten the manners that were supposed to guide their work. In the process of telling the truth, we have also transgressed the manners of academic rule books, the practices of other digital projects, and disciplinary standards. Forming these new standards was never an action item on our grant applications; they came into being through our project practices, habits of mind, and guiding principles. For us, telling the truth about our work means acknowledging the need to decenter the project director and reconceiving the project as a space of “collective and individual formation.” We may articulate specific goals and outcomes in our grant application, but necessary and productive deviations take place. What the RA makes and what the RA will become are not foreseeable by the director when she writes the Research Training Plan for the grant proposal, which specifies the necessary steps to make the RA. In fact, what Takeda and Landels wrote in the Training Plan came as a gratifying surprise to Jenstad. She was not — and could not be — aware of the full extent of their learning, precisely because liberatory pedagogy demands that the teacher not control the lessons. Indeed, just as the most interesting use of our data will not be what we think it is (Poston), the most interesting outcomes of the RA are not predetermined. Their ownership of the project means that they become collaborating agents, in charge of not just domains of expertise but also their own willingness to become. Takeda and Jenstad wrote this chapter in much the same way that the project itself is made: drawing on our respective expertise, experience, and critical inclinations; teaching each other; shifting tasks (research, visioning, writing, editing, and documenting) depending on who was best suited for the task in that moment; and working together to create something that neither of us could have made without the other’s input. Opening up the team structure and positioning the RA as the interface between the director and the research questions invites the “transgressive” moments that change and challenge the way we work. Here, we believe, hooks’s “vision of liberatory education” becomes possible, where allowing RAs agency connects the “will to know” to the “will to become” (18–19). In the process, the RAs become makers — the makers of new MoEML manners.

Notes

Bibliography