Remote Microsolidarity: Implementation of a Remote Collaborative Generative Process

# Remote Microsolidarity: Implementation of a Remote Collaborative Generative Process This is an implementation proposal created within the context of the Remote Microsolidarity crew for the general [Generative Process for Remote Collaborating on Generative Processes](https://demo.codimd.org/M4BCURgHSoWe-WBBlZVj3g?both). ## Context This document describes a fairly specific and somewhat rigid process for collaboratively developing a generative process. It likely seems like and initially will be a somewhat tedious process to implement. It is therefore useful to give it some context: 1. In some ways this is like **training wheels**. Once we get used to riding this bike TOGETHER it may seem more flowing, we may make changes to the mechanism in response to how we use. We will likely develop some cultural norms in response to it (which should make for an interesting outcome and reflection). 2. It is intended to allow for clear (and perhaps somewhat slow) **convergence** in a space where conversations tend to be divergent and lacking in followup. This requires some collective discipline/ 3. It is NOT intended to prevent or block **divergent conversation**, that can continue to whatever extent we wish to have it. However it is intended to help in discerning between the divergent and convergent movements. The convergent aspect needs a degree of protection from the divergent tendencies ... hence the rigidity and discipline. 4. What is not described in this document and deserves ongoing attention and care is how to find a good **shared rhythm and enable flow** for each of separately and for our collective efforts. This too may require changes to the mechanism and perhaps intentional (formal and/or informak) bypasses that prioritize flow ## Technologies ### 1: Process Document The process document will be a shared/collaborative document on CodiMD. It will contain a link to the audit log document ### 2: Audit Log Document The audit log will be a shared/collaorative document on CodiMD. It will contain a link to the process document. It is made up of two sections: 1. A table of contents that has the following columns: * Sequential Number * Date * Modification Owner * Modification title (short descriptor). * Modification outcome (accepted/rejected). 3. A main body where each log entry has a section. ### 3: Collaborative Processes The collaorative processes will take place in the Remote Microsolidarity Loomio space. ## Boostrapping with Sociocratic Consent Group decision making will, by defaul, be done using sociocratic consent. It can also be used as a bootstrap process to introduce other decision making processes. Sociocratic consent is intended to explicitly tap into implicit collective insights held by the group. In the spirit of the Alexanderian fundamental process, when done right, sociocratic consent yields low cost + low risk proposals that can be described as "good enough for now, safe enough to try." The core of sociocratic consent includes: 1. Making proposals. 2. Making sure that proposals are understood by the group by inviting requests for clarifications. Such requests may lead to a refinement of the proposal itself (in which case it is treated as a new proposal). 3. After clarifications, the group is invited to express objections to the proposals. Objections are offered as constructive criticism intended to refine the proposal. 4. Consent is given when a proposal reaches a point where expressed objections have been addressed (and there are no more standing objections). ### Sociocratic Consent on Loomio In order to keep a consent process cohesive and flowing we will be using an agreed protocol within a standard Loomio thread. We will not (at least initially) be using separate Loomio polls since that would create fragmentation both in process and resulting docmentation. #### Starting a Consent Thread 1. Start a consent thread by naming it using this naming convention for its title: *Seeking Consent - [Process Type]: [Short Descriptive Title].* 2. Use the thread "context" field to make your initial proposal. 3. Initiate the questioning phase (see below). The person who initiates a consent thread is its owner. #### Questioning Phase The purpose of the questioning phase is NOT to debate the proposal but to seek clarifications and create a shared understanding. The proposal owner opens a questioning phase by: 1. After starting the proposal thread (or a revision subthread) and making your proposal add a comment to it that starts "Questions" marked as HTML Heading 2. 2. Indicate in the comment the time-frame in which you wish to receive questions. 3. Explicitly invite to the thread the people whom you wish to involve in the consent process. The people who are invited to the consent process are its participants. Participants can respond to the proposal by replying to the "questions" comment within the thread. This can be treated as an open conversation (on topic!) within a Loomio thread. Participants who have no questions react to the "questions" comment with an "OK_hand" reaction. This is NOT agreement with the proposal, it is merely an indicator that you, as a participant, have no questions. When the time-frame for questions has passed, the owner: 1. Posts a comment to the "questions" comment saying: questions closed. 2. If the proposal stands (does not need to be revised in response to questions) continue on to objections (see below). 3. If the proposal requires revision/clarification, reply to the original thread with a comment that starts with "Revised Proposal" marked as HTML Heading2 and continues with the revised proposal. It is OK to copy the original proposal and make modifications to it. 4. If a revised proposal is published, the proposal owner once again initiates a question phase for the revised proposal. A questions phase can be considered mature/complete when all participants have responded to a proporal or a revision with an "OK_hand" reaction. It is then time to initiate an objections phase. #### Objections Phase The objections phase IS intended to debate the proposal with the intention of converging towards potential consent. Objections are offered to help the owner refine the proposal by addressing weakenesses. The proposal owner initiates the objections phase by: 1. Replying to the thread with a comment "Objections" marked as HTML Heading2. 2. Indicate in the comment the time-frame in which you wish to receive objections. Participants can express their objections by replying to the "Objections" comment. Each objection can become a hopefully constructive conversation. Participants who have no objections react to the "Objections" comment with an "OK_hand" reaction. This is NOT agreement with the proposal, it is merely an indicator that you, as a participant, have no objections. When the time-frame for objections has passed, the owner: 1. Posts a comment to the "objections" comment saying: objections closed. 2. If the proposal stands (does not need to be revised in response to objections) continue on to seeking consent (see below). 3. If the proposal requires revision/clarification, reply to the original thread with a comment that starts with "Revised Proposal" marked as HTML Heading2 and continues with the revised proposal. It is OK to copy the original proposal and make modifications to it. 4. If a revised proposal is published, the proposal owner once again initiates a question phase for the revised proposal. An objections phase can be considered mature/complete when all participants have responded to a proporal or a revision with an "OK_hand" reaction. It is then time to initiate a seeking consent phase. #### Seeking Consent Phase At this point consent can likely be assumed, but is explicitly sought. The proposal owner initiates seeking consent by: 1. Replying to the proposal thread with a comment "Seeking Consent" marked as HTML Heading2. 2. Indicate in the comment the time-frame in which you wish to receive consent. Participants can respond by: 1. Adding a reaction "thumbs_up" for giving consent. 2. Adding a reaction "thumbs_down" for denying consent. 3. Comments can be added to express additional thoughts or sentiments. 4. If consent is denied, a comment is expected to give some context as to why. #### How Does It Feel? Phase This phase is documented here as part of the sociocratic sequence though (to the best of my knowledge) it isn't formally a part of it. Therefor it is not directly triggered from within the sociocratic process but from within a specific collaborative process (Apply the Modification) described below. ### Consent Implementation of Collaborative Processes #### Identify Intervention Point Identifying a potential to modify the generative process can take place anywhere and any time within the crew collaboration. It can be seeded in a live meeting, in a Loomio thread, in the chat. Therefor this is not really a process. Rather this is an invitation to be attentive to opportunities for improving (increasing the life and wholeness of the process). #### Initiate Intervention Make a proposal indicating where in the generative process you believe a change is needed by initiating a consent thread on Loomio: 1. Use "Initiate Intevention" for the [process type] of the thread title. #### Propose a Modification Make a proposal indicating what changes you wish to make to the generative process by initiating a consent thread on Loomio: 1. Use "Proposed Modification" for the [process type] of the thread title. 2. In the beginning of the proposal provide a link to the "Initiate Intervention" proposal thread that led to the modification proposal. #### Apply the Modification This process is to be executed by the owner of the modification proposal. 1. Make the proposed changes to the generative process document. 2. Add an entry to the audit log document (see details below). The proposal owner then initiates a "How Does it Feel" phase by: 1. Adding a comment to the proposal modification consent thread that starts with "Applied - How Does It feel" marked as HTML Heading2. 2. Indicate in the comment the time-frame in which you wish to receive feedback. Participants can respond with comment and reactions to the modified process. When the time-frame for feedback has passed the owner of the proposal initiates an "Review the Modification" collaborative process (see below). #### Review the Modification This process gives everyone an opportunity to decide if the modification truly enhances the wholeness of the generative process and to decide if it to be accepted (committed to the process) or rejected (set aside). The proposal owner respons to the modification proposal thread by: 1. Adding a comment that starts with "Accept Modification?" marked as HTML Heading2. 2. Indicating in the comment the time-frame in which you wish to receive a decision. Participans can respond with: 1. Textual comments. 2. A "thumbs_up" to keep the modification. 3. A "thumbs_down" to reject the modification. #### Accept the Modification If a modification is accepted, the proposal owner: 1. Add an Audit Log Entry 2. Add a comment to the proposal thread that starts with "Outcome: Accepted" Log Entry: [log sequential number]. #### Add Audit Log Entry 1. Add a table-of-contents entry to the table of contents of the audit log document. 2. Add a log entry section to the document: * Create an H3 title structured: [sequential number]: [Modification Title] * Create a line structured: by [proposal owner] on [date added] outcome [outcome: accepted/rejected] * Create an H4 title: Driver * Add a link to the "Initiate an Intervention" Loomio thread. * Add a link to the "Propose a Modification" Loomio thread. * Add a short description (you can copy paste from the relevant threads) of the driver. * Add an H4 title: Modification * Add a full description of the modification made to the process. * Add an H4 title: Echoes * Add any echoes that were evoked by the modification.