Outline of Key Documents Project & KeyCode Process

Objectives

The set of Key Documents (Key Docs), authored by Caroline Savery and Marco V Morelli, launching Dec 2017 and located at this directory, serves a dual purpose:

1. To present a clear communicable picture to existing and potential stakeholders
   1. Visible to the public on Cosmos.coop
      1. For the purpose of informing current members and supporters
      2. Also for the purpose of informing and attracting potential supporters, members, contributors, partners, investors, etc.
2. To initiate a process of group development about the direction, plans and norms of Cosmos
   1. Members can participate in each page’s discussion on the forum — for the purpose of critiquing, amending and developing the quality and authenticity of the content toward fulfillment of Cosmos’ mission.

The process mentioned in #2 is called the Key Documents (or Key Docs) To Conversations To Codex process. Or KeyCode for short.

Background

Over several meetings, Caroline Savery and Dr. Avery Edenfield of Utah State University, who is offering his expertise on the process (as part of his scholarly work about cooperative organizations’ documentation methods), developed a proposed process for undertaking a collective documentation process in Cosmos.coop.

The Issue

Caroline and Marco as key cofounders and developers of Cosmos have invested many hours over the last 16 months developing the concepts for Cosmos. This material has not been adequately shared with the general community. There is a need to communicate about our thinking and embark on a more participatory co-creation process; ultimately, whatever becomes Cosmos canon should be functional, transparent, and member-informed. So, how to get from where we are, to where we need to be?

Some key considerations that emerged from the collaboration:

• It felt wrong to establish material heavily worked on by Caroline and Marco as the first draft of an official codex. We want the ultimate documentation to emerge from a member-led participatory process, although we acknowledge that whomever creates a first draft of anything has indelibly left their “imprint” on the history and culture of the organization. We want to present in-depth material while also transparently notating who the authors are.
• What would living documentation look like?

Simplified Phase 1 of Proposed Process

Caroline publish the Key Docs as webpages on Cosmos.coop, integrated with the forum. Caroline will also participate in, coordinate participation, and assist in facilitating conversations on these pages. In the process, Caroline will recruit and coordinate further team members to lead conversation processes in various domains, and people to serve in facilitator roles (see CDT below).

Proposed Full Process

The Key Docs > Conversations > Codex (KeyCode) FULL PROCESS:

1. Releasing co-founders’ “best thinking” to the community in the form of the Key Docs
   1. Authorship acknowledged: author of every version of a text linked to that version for transparency
   2. Publicly visible pages with forum integration for discussion
      1. This enables the dual function of outreach about Cosmos using the key documents, and ongoing member engagement about the documents.
2. Deliberately engaging with and facilitating discussions among membership on Key Docs content
   1. Members engaging on the content:
      1. To delve into big, unanswered, open questions embedded in the texts
      2. To give feedback, friendly amendments, concerns, etc. on the content itself
      3. THIS INCLUDES discussing appropriate ownership and control rules that would govern Cosmos and the Codex itself, once created.
   2. Participants in the discussions would be recruited and empowered to perform in facilitator roles. The team of such people are called the Codex Development Team (CDT).
      1. The role of the facilitator in any one of these conversations is unique: he/she/they
         1. Urges the community to “consent” on pushing some language, emergent from the discussion, to update the version of the page
         2. Monitor related conversations and provide supportive facilitation for other discussion conditions, like stagnation, divergence, convergence, etc.
         3. Implement/ensure implementation of proposed updates to the final copy.
      2. Like facilitators, they’d use various skills, methods and tools to accomplish this. Some examples:
         1. “[Insert Name], could you propose language for the Codex that summarizes our talks here?”
         2. “[], what do you think of that? Does that address your concerns?”
         3. “Maybe we should break into two caucuses to further develop these two distinct proposals, then come back together here.”
         4. Etc.
      3. There might also be some platform-automated type functions. Some possibilities include:
         1. When a proposal is submitted, a bot reminds everyone on the thread to vote on it by a certain time.
         2. When a discussion is dormant, a bot reminds folks that the conversation will automatically be archived if no (non-bot) activity happens on it by (X) months from the time of the last comment.
3. The Codex is handled and developed by the Codex Development Team (CDT)
   1. The Codex’s content is formed by “pushing” things from a transparent discussion, development and revision process into canonical documentation. The ultimate contents are “blended”–starting from M+C’s content, digested/worked through by the community, some amalgamated output makes its way into the Codex.
   2. In a mature version of this process, we envision any member of sufficient trust being able to publish a page as a proposal, engage member discussion on it in dedicated spaces using dedicated staff support (CDT), and be able to create high-quality crafted pages that can be compiled into an attractive online ebook (Codex as ebook)!

Codex Development Team (or CDT): Skilled facilitators of discussion (even moderators, to some extent), who act to distill the community’s best ideas (and who maintain linkage with the original conversations for transparency).

As this process grows in scale, CDT facilitators would be monitoring numerous topics potentially on a wide range of material. For fairness’ sake, we could have:

• 1 CDT needs to check another CDT’s work before final approval of a Codex change
• CDTs are randomly assigned to topics or to checks of peers’ work
• The CDT working in any given conversation may rotate (or would rotate on an objective schedule), so no one person gets too entrenched in an issue they are personally passionate about.
• Members can request a CDT change if they suspect bias in how the CDT is shaping the conversation. Another CDT would automatically be assigned. Multiple complaints and a peer CDT would review the complaints and the patterns in the CDT’s actions and seek mitigation.

CDT would be a particularly powerful, and thus trusted role. CDTs like any “distributed worker” in Cosmos’ framework would compensated by Cosmos for their work.