I have several plans for how to work with PECE going forward.
Firstly, I want to write about what it means to "be a backend person" for digital humanities projects. Specifically, I want to explore how those "backend" people do work to "translate" (maybe not the best word) the hopes of the "frontend" people into reality. For example, when Kim says we need a PECE essay, how does code and sysadmin work mediate Kim's vision into reality, and how does Kim's vision change as backend code and sysadmin work takes shape, and how does Kim's changing vision change code and sysadmin work. I think this is important to talk about, especially as we have previously envisioned PECE as a triptych of frontend-middleend-backend, but with each tine being differently visible.
I also want to write specifically about the need to develop sysadmin best practices for PECE specifically and digital humanities more broadly. I think it's time for us to explore the people of PECE more concretely and probe how people who may never ever (and may have no interest in) ever writing an annotation or uploading an artifact nonetheless are crucial in the broader collaboration and success of the frontend collaborations.
Secondly, I intend to continue to use PECE in the classroom. Brandon and I last semester put forward a grant for seed funding at RPI (unfortunately unfunded) to use PECE in several new courses focused on data analytics, ethics, stewardship. We had brainstormed some potential courses bringing together ITWS and STS students around these issues, using PECE as the backbone for collaboration.
Finally, I may end up getting interested graduate and undergraduate students who will need coding work for classes/independent studies. I'd like to identify places where those ITWS students could contribute to PECE's codebase.
I've thought a lot about how PECE suffers from the bus problem (if one of us gets hit by a bus, what then happens to the knowledge of that person in maintaining and sustaining PECE?). I recently had a moment to reflect on this with Drex, who set up Ali K's PECE instance at Drexel. While we do have relatively good documentation for the installation and long-term maintenance of PECE, there were some glaring omissions due to little more than the fact that PECE as a software suite is a constantly moving target, and part of that suite is all its interlocking parts. I had come to realize that newer versions of our operating system did not have the same breadth of tooling that previous versions of the operating system (that TAF/WP.org/DSTS run on) have. I made a tracking bug here: https://github.com/PECE-project/drupal-pece/issues/26
Some part of that is constant iteration on our documentation, which I have not been hyper-diligent on. I make tweaks as I notice things, but if I don't notice something (like this latest discrepency with Drex) then the documentation doesn't get updated. I'm not entirely positive what the best course of action is. It's unreasaonable to have me or anyone else install a fresh PECE instance every few weeks just to make sure the installation instructions are OK. But a good first step might be to organize a doc sprint (https://developer.mozilla.org/en-US/docs/MDN/Community/Doc_sprints) every 3-6 months on a topic. It would only take a day, can be done virtually or in-person, and would give us a defined space to test out our documentation and make changes and additions as needed.