In my previous blog (‘Introducing the ‘Software Paper’), I introduce the Software Paper at Computational Humanities Research (CHR). In tandem with my editorial work as Associate Editor for the journal, an opportunity arose for me to write a Software Paper myself.

I’ve been working for some time on a Python package called Undate, generalizing implementations from a couple of projects for working with partially known dates and multiple calendars. I had hoped to publish on the work eventually, when I got the code to a fully-featured, stable 1.0 release. But CHR’s themed issue on Missing Data in the Humanities was a perfect fit, which prompted me to start writing about the work sooner than I might have otherwise – and I’m glad I did.

Writing about Undate was an act of articulation, reflection, translation. I’d been thinking about these problems for so long across projects and with my collaborators, but had been focused on the technical implementation and practical application. It was incredibly valuable to take time to tell the story of why and how this software came to exist, articulate the humanities research methodologies and theories embedded in the decisions in the code, and share the impact we hope this project will have.

It was only when we had written a nearly complete draft that I finally figured out how to describe what it is I’m trying to do: this is an “ambitious, in-progress effort to develop a pragmatic Python package” which I hope will make it easier for people to work with temporal data in more nuanced, humanities-specific ways. We had a little trouble figuring out how to fit all the things we wanted to discuss into the documented structure of a Software Paper, because we were writing both about the projects that Undate builds on and generalizes, and also about other projects working in the same problem space. I had the rather unique experience of a reviewer helpfully directing us back into revising our paper to better fit the documented structure of a CHR Software Paper; this is why the final version has subsections on related projects and other approaches within the section on related software. I had the interesting experience of both reviewers helping improve not just the paper, but also sharing suggestions to improve the software.

I also had the opportunity to try out CHR Notebooks, which enabled me to provide code notebooks for three of the figures in the paper. These are published by Cambridge alongside the article, and the figure captions link to the code. This should provide reproducibility and transparency for my work, and in two of my figures showcases the use of the Undate software. I think this is a particularly interesting option for Software Papers (although not only those), and I look forward to seeing how others use it.

Writing a Software Paper is an act of articulation and translation because it’s a chance to make the thinking and decisions embedded in code more visible externally. Depending on the software, those who are technical enough may be able to “read” the interface and understand or guess at what’s going on underneath, but it’s hard to go deep without really engaging closely with the code.  This came up in a recent conversation on my team about code comments: we’re not just describing what the code does, but why we are doing it that way. The specific implementation may change later, but the reasoning behind it is important.  The CHR Software Paper is a chance for researchers who develop software to articulate their thinking and decisions and consider the impact of that work.

I encourage everyone to read Software Papers as they are published. Our Software Paper on Undate is now available open access in CHR: Undate: humanistic dates for computation (2025), by Rebecca Sutton Koeser, Julia Damerow, Robert Casties and Cole Crawford.