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.
