What ideas have you had about ways to sustain and govern PECE and TAF as both continue to develop? What infrastructure, communication, and coordination will effectively support new collaborators?

Annotations

Enter a comma separated list of user names.
Angela Okune's picture
July 8, 2019

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.

Brian Robert Callahan's picture
July 6, 2019

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.

Lindsay Poirier's picture
July 6, 2019
  1. I've been getting lots of feedback that folks don't know where to begin with PECE. I think there should be a single location for new users (both those that want to use PECE and want to download PECE) to find all of the materials that they need to get involved. This can be linked out to other resources, but should be the first place they are directed to find all other relevant materials. I believe that the Read the Docs is the best place for this and that the World PECE instance is not the best location for this, because posting it there assumes that new users already know how to navigate PECE (and because we have so many instances now that users primarily planning to use TAF or STS Infrastructures would get confused). The problem with the Read the Docs right now is that it is very long and ominous, so I would really love to see some very simple "Getting Started" material designed for this page (perhaps by newer users who have recently learned how to use a feature). 
  2. Slack could be a really great space for new users to ask questions, but right now it is under-used. I'd like to know more about whether this is just because of low activity or if folks generally don't want to use it.
  3. Weekly PECE meetings could help those who want to be more involved to have a space to do so. Also an infrastructure for recording tasks and assigning deadlines could help with accountability. (With Waffle.io closing down, we need a different system for this; many require purchasing a pricing plan). It would be great to have a designated space to account for the different PECE projects that we have underway. Right now we have pieces of many of these projects recorded in Google Docs, World PECE, and/or email, so it can be difficult to keep track of where we are with them. But if we build it, will they come?
  4. My biggest ask - I'd really like to see some form of a project manager hired to help with scheduling meetings, staying on top of deadlines, and managing our collaborative infrastructure. A PECE grant could help with this. I'd like to plan to stay on top of the ODH grants this year.
  5. I'd like to think more about how we can communicate to new users how PECE is a work-in-progress, and that, as an experimental system, it hasn't been designed to privilege a tight organizational structure (and sometimes favors serendipity over discoverability). There are ways to design a PECE instance to have a tighter structure and to make things more discoverable (with protocols and style sheets), but this assumes deep knowledge and experience with the platform that new users just won't have. Since our design logics have been core to the platform from the beginning, it will be important to find ways to communicate them to new users so that they can understand what they are signing up for. 
  6. Once the PECE newsletter starts getting published monthly, I'd like to see a list of current PECE projects, along with a call for collaborators, posted in the newsletter. 
brcostelloekuehn's picture
July 4, 2019

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? 

July 1, 2019

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.