AO: I think ways to decentralize the technical maintaince from just one or two people and ways to build more tech capacity to sustain and further develop PECE are needed. Need to think about the responsibilities for someone seeking to set up their own instance. What is required of them (what does PECE design team want fed back; are there any use cases PECE design team does NOT want?; how will the proliferation of diverse projects begin to get involved in decision making about PECE? Not just about TAF... How can/should others get involved in the decision making?) There are several governance models that could be used - each should be reflected on and thought about for pros/cons.
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.
I don't have a clear answer to this big question, but I do think it could be interesting to experiment with governance systems like sociocracy, or with design process approaches like regenerative design, or with design principles drawn from observations of patterns in living systems specifically applied to the governance/design of the project overall. I'm compelled by the Design Logics that have been developing in parallel, and intersecting with, the design of PECE -- I wonder how these Logics could be applied to the broader governance of the project(s) overall? I wonder what happens when we oscillate the figure/ground of project/platform and governance/broader collaboration?
One focus needs to be on making PECE more user friendly. The user documentation, videos etc. don't seem to work for the majority of users -- we have tried running tutorials over virtual calls as well, also with mixed success. If one of the goals is to broaden the user base of PECE, if only to showcase possibilities for experimental ethnographic work, we need to work towards making it easier as platform for folks to work with.
Besides that, many of us are beginning to work with PECE for various spin off projects. Being able to write PECE into our grant applications helps, and this can also work synergistically to support further development of PECE. We have conversations in relation to this, but these haven't yet crystallized into concrete mechanisms that we could follow. Perhaps something to follow up at the Ecuador meetings.