---
# System prepended metadata

title: A Generative Process for Remote Collaboration on Generative Processes

---

# A Generative Process for Remote Collaboration on Generative Processes

## Introduction & Context
This document assumes some background (that is not a part of this document) about Christopher Alexander's ideas and terminology around centers, wholeness, unfolding wholeness and generative processes. This background was established (and is being nourished) in the crew exploring Remote-Microsolidarity.

### Christopher Alexander
This document is based on Christopher Alexander's **Fundamental Process**. It describes a meta-process through which a small group can create remotely and asynchronously generative processes. 

### Living Processes
It takes time (sometimes generations in the physical world) for a generative process to mature and stabilize. Therefore this meta generative process and the generative processes created with it are best though of as living beings. They will probably require iterative refinement (in the spirit of this meta process) in response to their application in the world.

This process assumes the existence of a base process which lends itself to unfolding. It does not address the question of seeding a new process. 

### Implementation
This document does not include specific implementation details about the collaborative processes that are actually used. A separate implementation document can be authored to describe these implementation details in different group and different contexts. 

The Remote-Microsolidarity team will be creating one such implementation document to shape the way they will collaborate. 

### (Initial) Tediousness
This process may seem (and initially feel) somewhat tedious. This tediousness may be relieved when a group becomes experienced and established in its implementation tools and processes. The tediousness is an indicator that in a subtle but important way, wholeness takes precedence over comfort. 

## Process: Core
This process is to be applied iteratively when modifying a generative process. 

1. **Witness the Process**. Before doing anything to the process, take in the wholeness of the process as it is. Spend some time with it. Hold it in your heart and allow it to live in the back of your mind. See what feelings it evokes in you. Discover what about it shimmers for you and where you feel latent potential that needs to be given more attention and life.
2. **Identify Intervention Points**. Give special attention to the weak points and to latent potentials (gaps in the process that you sense are present but not yet identified and described).
3. **Initiate Intervention**. Use a collaborative group process to coordinate and agree on where the next intervention should be. In any given process there can be only one point of intervention at a time.
4. **Propose a Modification**. Use a collaborative group process to explore, discuss and author a modification at the point of intervention. The proposal should include an indication of which team member is the owner of this modification.
5. **Apply the Modification**. Subject to the outcomes of the collaborative proposal, add the modification to the core process. Add an audit log entry 
6. **Review the Modified Process**. Witness the process again. Does it still feel whole? Does the modification feel seamless? Has the wholeness of the process been enhanced by the modification? Has the modification violated any of the established parts of the process? 
7. **Review the Modification**. Use a collaborative group process to decide if the modification is to be accepted to the process. 
8. **Accept the Modification**. If the group decides to keep the intervention leave it in the process. Add an entry in an audit log to indicate the modification. See process: Add Audit Entry Log.
9. **Reject the Modification**. If the group decided to reject the internvetion, take it out of the process. Add an entry in an audit log to indicate the rejection of the modification. See process: Add Audit Entry Log.

## Process: Add Audit Entry Log

This process is used to maintain an audit log of changes/transformations that are made to a process. It is intended to provide some context into what drove the changes and the decision making around them.

It is recommended that the audit log itself have one owner responsible for its creation. Yet, the creation of the entry itself can, and probably will benefit, from a collaborative process where everyone can provide input and the owner can integrate.

1. **Create New Audit Entry**. Create new entry in the audit log indicating when a modification was made and by whom.
2. **Describe the Modification Driver**. Give some context (textual description) about the reason that the modification was initiated. If possible link to  resources (discussions, decisions, other group processes) that led to the initiation of the modification.
3. **Describe the Modification**. Describe the modification that was created in response to the driver. 
4. **Indicate Outcome**. Indicate the outcome of the modification (Accepted, Rejected).
5. **Describe Decision Context**. Give some context (textual description) about the decision process that led to the outcome.
6. **Echoes**. If there are any, document echoes that the modification generated. Eg: In case of acceptance, describe the effect on the wholeness of the process; In the case of rejection, describe the objections that led to the rejection and if there are elements of the modications that may be considered/reconsidered at a later time.



