Document ALL the things!

We are pleased to announce the publication of four project charters (ranging from 2016 to 2019) and two pieces of software documentation: the “Built by CDH” warranty and long term service agreement documents. These charters are works of scholarship, and we’re excited to be publishing and sharing them more widely.

There was renewed interest based on recent conversations at ACH2019, both in how we charter and plan our projects, and in how we maintain them. In a session on Infrastructure and Capacity Building for Sustainable Digital Projects, Jean Bauer mentioned that, while at the CDH, she wrote a “living will”, with plans to handle degradation. (The “living will” was later renamed with the more standard, though less evocative, label of “Long Term Service Agreement.”)

Project management is one of our strengths and there's been interest in our project management and process documentation for a while, most notably after the well-received panel at DH2018 in Mexico City on project management, to which Natalia Ermolaev, Rebecca Munson, and Xinyi Li all contributed. Natasha and Rebecca have also given multiple workshops on project management, at Princeton and elsewhere.

Our charters also came up at the State of Digital Humanities Software Development Roundtable in conversation about how we plan and manage projects and, particularly, how we set and reinforce boundaries. Among other software development management techniques, I discussed the notion of the “Minimum Viable Product” from Lean software development. As you’ll see in the project charters, this is one approach we’ve used for scoping projects, and is one way that these are a work in progress (careful readers will also notice detailed work plans that quickly became inaccurate). Like many teams we can’t accurately predict how fast development and data work will go, so we’re continuing to think about how to plan projects effectively and revise our approach as needed.

Our collaborative process has changed over the years, and that’s reflected in changes in the structure of grants that we offer as well as in the charters. We’re sharing here a sampling of different charters from different years. They may be interesting for historical reasons, but they also demonstrate that the kind of charter you need depends on the kind of project and the size of the team.

The most important change we’ve made in our grant structure is to split out dataset curation work from research partnerships that are “Built by CDH.” We provide a lightweight charter template to dataset curation participants (see PDF template linked below), but we don’t require recipients to write one. Our most recent charter, for the Princeton Ethiopian Miracles of Mary project, is actually a bit of a hybrid: the project director Wendy Belcher is a previous recipient of a dataset curation grant, and there is still a substantial amount of data work to do, but the CDH Development & Design Team is supporting the project at a higher level than a dataset curation project, including exploratory work for future implementations.

For those who are interested in the technical implementation details, take a look at the design plan section of the charter. These are written by the technical lead to provide a high-level overview of the planned approach for the project. I’m proud of my contributions to the PPA and PEMM charters, and glad to be prompted at the beginning of a project to think through and articulate my approach and solicit feedback from colleagues. My hope is that sharing these now is a step towards cross-institutional conversations about technical infrastructure and software frameworks that are important for DH developers, as Shane Lin pointed out.

In the future, we plan to publish new project charters after they are completed and signed. Making this a standard procedure may increase the quality of the document slightly, and planning to publish from the outset will certainly simplify getting permission from contributors (rather than having to track them down after the fact, as we have done for these documents). It also means that if people are interested in giving us feedback, it can happen in a more timely fashion. Rebecca Munson is working on a brief history of our charter process with reflections on how refinements over time fit our changing views on projects as both collaborative endeavors and process-based scholarship, which I’m looking forward to reading and sharing soon.

Charters

For more on what a charter is and how they are written, read an overview of our project charters and the chartering process.

CDH Project Charter — Derrida’s Margins 2016-17. (2016)
Derrida’s Margins; this charter was written before the CDH Development & Design Team had been formed.
https://doi.org/10.5281/zenodo.3359144

CDH Project Charter — bitKlavier 2017-18. (2017)
bitKlavier. CDH staff consulted on the project, but were not involved in the implementation.
https://doi.org/10.5281/zenodo.3359176

CDH Project Charter — Princeton Prosody Archive 2017-18. (2017). Charter for the most recent development phase of Princeton Prosody Archive. CDH Development & Design Team actively involved in planning and implementation.
https://doi.org/10.5281/zenodo.3359172

CDH Project Charter — Princeton Ethiopian Miracles of Mary 2019-20. (2019)
Charter for continuing data work and exploratory implementation work for Princeton Ethiopian Miracles of Mary. CDH Development & Design Team actively involved in planning and implementation.
https://doi.org/10.5281/zenodo.3359178

Maintenance agreements

These documents apply to projects developed by the CDH Development & Design Team under a Sponsored Project (under previous grant structure) or Research Partnership grant.

“Built by CDH” Software Warranty. (2018)
Warranty for the first three months of a project after public launch.
https://doi.org/10.5281/zenodo.3359198

“Built by CDH” Long Term Software Agreement. (2018)
Maintenance in the longer term, with contingencies for handing off a project or archiving it and turning it off.
https://doi.org/10.5281/zenodo.3359203

All charters and maintenance agreement documents are released under a Creative Commons Attribution 4.0 International License.