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.
