Everything, All at Once, Yesterday: Creating Research Software with Humanities Faculty

Wieringa, Jeri E.; Naydan, Mary

doi:10.5281/zenodo.17315342

Everything, All at Once, Yesterday: Creating Research Software with Humanities Faculty

Wieringa, Jeri E.; Naydan, Mary

Publisher: Zenodo
DOI: 10.5281/zenodo.17315342
Repository: zenodo.org
Language: en

Abstract

A humanities faculty member comes to you with a grand idea for a digital research project. As a scholar of literature, they want to trace how the depictions of extraterrestrial beings in works of science fiction change over time. Because they want to look at historical changes in the genre at scale, they intuit that computers are needed for this task, but have no knowledge of programming, software engineering, or data. Where are the texts you want to look at? you ask. Luckily, the researcher replies, most of the texts already have digital versions available in the university library catalog! Taking a different tack, you inquire, what is your research question? The researcher replies that they are interested in how the science fiction genre encodes the history of colonialism on Earth; however, they are most interested in creating a beautifully-designed public-facing tool – with an interactive timeline, map, and search bar – that scholars in their field will use to answer many possible research questions. For Research Software Engineers in the humanities, this scenario is commonplace. Unlike our peers in the sciences and social sciences, humanities scholars by and large approach scholarship as a solitary endeavor, the exploration of a topic or idea through the materials of the archives and theoretical frameworks of the field. By contrast, digital and computational scholarship in the humanities is collaborative by necessity; few humanities scholars are able to do computational work on their own, and most acknowledge that the most interesting and innovative work happens in collaboration with partners skilled in software engineering. At the Center for Digital Humanities at Princeton, we focus on transitioning humanities faculty from individual scholars to co-PIs on digital scholarly projects. One of the only Humanities RSE teams in the United States, we work with Princeton faculty on short-term (6-12 month) development projects, as well as provide project design training and data development support. Our primary focus is on projects where the humanities research questions require innovation in software or computational methods. In this talk, we will highlight our chartering process, whereby we guide the expansive and often not-operationalized research questions of our faculty collaborators into a defined research and development plan. These processes build on foundational theoretical work by early digital humanists like Simon Appleford, Jennifer Guiliano and others, and have evolved alongside the RSE role [1]. The charters are written collaboratively, guided by our project manager and shaped by the faculty member and our research software engineers over the course of a month. The process of chartering is a key part of our work in transitioning humanities faculty from their traditional modes of research and scholarly exploration into the space of digital and computational research, teaching them to understand their sources as data, transforming their ideas into research questions that are modular and operationalizable, and shifting their process from individual to collaborative. Using our most recent project charter as a case study, we will showcase the central role that project management plays in facilitating what Jason Boyd calls “scholarly exchange” [2, 3]. Ultimately, our talk will show how doing software engineering work in a humanities context poses particular challenges, but also provides the unique opportunity for the RSE to shape the faculty PI’s research questions and approach. References Appleford, Simon, and Jennifer Guiliano. “Best Practice Principles Of Designing Your First Project.” DevDH.org, 2013. http://devdh.org/lectures/design/bestpractice/. Boyd, Jason. Digital Humanities Project Management as Scholarly Exchange. IDEAH 2, no. 2 (2022). https://doi.org/10.21428/f1f23564.a4156d43. Naydan, Mary, Bennett Nagtegaal, Rebecca Sutton Koeser, and Edward Baring. “CDH Project Charter — Citing Marx 2025.” Center for Digital Humanities at Princeton, February 12, 2025. https://doi.org/10.5281/zenodo.14861082.

Full text

Everything, All at Once, Yesterday Creating Research Software with Humanities Faculty Jeri E. Wieringa, PhD Mary K. Naydan, PhD Research Software Engineering at the Center for Digital Humanities @ Princeton First, a skit to set the stage… What is going on here? https://www.menti.com Code: 1599 5744 What is going on here? ●They don’t have a clear research question ●They want a lot of disparate things (with no sense of effort or complexity) ●The audience for the project is vast and undeﬁned ●The source base is complicated and not ready for analysis ●They are not inclined to engage in the process So what do we do? What does a successful collaboration look like? ●A clear deliverable (dataset, software, research infrastructure) that supports a humanities scholarly output (journal article, book). ●Increase in Princeton humanities scholars using and invested in digital methods. ●Opportunity for the RSE team to make a contribution to the ﬁeld of Digital Humanities (method, tool, critique). ●Co-ownership model for a more resilient collaboration. How do we get there? Faculty Training “Project Design” Workshop ●Portfolio versus project PORTFOLIO PROJECT PROJECT PROJECT PROJECT Faculty Training “Project Design” Workshop ●Portfolio versus project ●Types of digital humanities outputs PORTFOLIO PROJECT PROJECT PROJECT PROJECT Faculty Training “Project Design” Workshop ●Portfolio versus project ●Types of digital humanities outputs ●Modular and sequential thinking PORTFOLIO PROJECT PROJECT PROJECT PROJECT TIME (YEARS) The Project Charter ●Collaboratively written over the course of ~1 month The Project Charter ●Collaboratively written over the course of ~1 month ●Acts as the project’s foundational document The Project Charter ●Collaboratively written over the course of ~1 month ●Acts as the project’s foundational document ●Acts as a contract to ensure all team members are on the same page The Project Charter ●Collaboratively written over the course of ~1 month ●Acts as the project’s foundational document ●Acts as a contract to ensure all team members are on the same page ●Deﬁnes the project’s goals, scope, deliverables, & organizational infrastructure The Project Charter ●Collaboratively written over the course of ~1 month ●Acts as the project’s foundational document ●Acts as a contract to ensure all team members are on the same page ●Deﬁnes the project’s goals, scope, deliverables, & organizational infrastructure ●Expresses the team’s commitment to a set of ethical values The Project Charter The Project Charter The Project Charter The Project Charter The Project Charter The Project Charter 100% (2) humanities faculty report this was their ﬁrst time working collaboratively The Project Charter Chartering Outside the CDH Speciﬁc to Princeton Humanities context: ●Primary objective is educational ●Humanities faculty in particular are not trained in collaborative or computational research practices Widely Applicable Components: ●All collaborative projects beneﬁt from documented goals, deliverables, scope, and responsibilities ●Platform for advocating for the scholarly value of the software Conclusions ●Using Charters to turn “magical” computational elements into part of the Humanities research process. ●Educational work paves way for more equitable relationship between researchers and RSE team. ●We know this works for Humanities scholars and propose that it may be useful more broadly. Scan for a copy of the CDH charter template