Skip to content

This document is a provisional draft written before the formal establishment of the first circle.
It defines the initial structure for collective refinement.
Upon founding, the circle will review, amend, and formally adopt or reject each section.

How We Change Together

Purpose

These documents are living guidelines, not scripture. They evolve through transparent peer review, tested in practice, refined through collective discernment.

This process protects core principles while enabling adaptation.

Philosophy

  • Transparency: All changes visible and discussable through pull requests
  • Peer Review: Collective discernment using Quaker-inspired process, not hierarchy
  • Experimentation: Test one change at a time, evaluate in practice before adoption
  • Protection: Core principles (attention, honesty, compassion) remain stable while structure adapts
  • Reversibility: Changes can be reverted if they prove harmful in practice
  • Practice over theory: Theory serves practice, not the reverse

How to Propose Changes

→ New to GitHub? See How to Contribute Changes for a step-by-step guide with screenshots.

Starting a Discussion

Before proposing changes (especially for Tier 2 and above), start by opening a GitHub Issue to discuss your idea with the community.

Think of it as a discussion thread or suggestion box where anyone can: - Propose ideas for improvement - Ask questions about existing practices
- Share what's working or not working in their circle - Discuss whether a change aligns with core principles

You don't need technical skills to open an issue—you're just sharing an idea. If there's support, you or someone else can create a formal proposal (pull request) later.

Change Tiers

Tier 1: Small Improvements

Examples: Typos, grammar, clarity improvements, formatting

Process: 1. Submit pull request with clear description 2. Requires 1 approval from any reviewer 3. No testing required 4. Merge when approved

Tier 2: Structural Changes

Examples: New sections, reorganization, additional resources, modified language

Process: 1. Open GitHub issue first to discuss proposal 2. Explain: What problem does this solve? How does it align with core principles? 3. If there's support, submit pull request 4. Requires 2 approvals from different contexts 5. Testing recommended but not required 6. Merge when approved and discussions resolved

Tier 3: Experimental Changes

Examples: New practice formats, session structure changes, facilitation approaches, documentation methods, governance modifications

Process: See "Experimental Branch Process" below

Tier 4: Core Principle Changes

Examples: Changes to purpose statement, core values, conflict resolution, departure policy, fundamental freedoms

Process: 1. Must be proposed by or endorsed by a formed circle 2. Requires experimental testing and formal meeting(s) 3. Discussion period (minimum 2 weeks after testing complete) 4. Multiple circles should weigh in 5. Formal meeting with 2+ circles represented (minimum 8-12 participants) 6. Requires 3+ approvals from different contexts after meeting consensus 7. Merge only with clear unity sensed across multiple contexts

Quaker-Inspired Discernment

We use a consensus-based approach inspired by Quaker practice, adapted for asynchronous collaboration through pull requests.

Core Principles

  • Seek unity, not majority: Approval isn't voting; it's collective discernment
  • Speak from experience: "This helped/harmed my circle" > "This seems wrong"
  • Listen to understand: Read thoroughly before responding
  • Silence matters: Sometimes not commenting immediately allows clarity to emerge
  • Stand aside vs. block: You can disagree without blocking if it doesn't violate core principles

Review Meanings

✅ Approve = "I sense this serves the intention" - Aligns with core principles - Has been tested or seems sound - Improves clarity or function - I trust this direction

💬 Comment = "I have questions/suggestions" - Not blocking, but offering perspective - Seeking clarification - Suggesting alternatives - Sharing relevant experience

⚠️ Request Changes = "This needs work before merging" - Specific issues to address - Concerns that need resolution - Not necessarily opposed, but not ready

🛑 Block (rare) = "This contradicts our foundation" - Use sparingly and seriously - Only when core principles are threatened - Must explain why clearly - Opens deeper discussion

Review Criteria

✅ Green Light (Approve) - Improves clarity without changing meaning - Fixes errors or inconsistencies - Adds helpful resources or examples - Aligns with existing principles - Makes structure more accessible

⚠️ Discussion Needed - Changes meaning or interpretation - Adds new structural requirements - Removes existing guidance - Affects multiple circles differently

🛑 Core Protection (Block or Request Changes) - Introduces hierarchy over federation - Compromises transparency - Reduces autonomy - Contradicts attention/honesty/compassion - Creates barriers to participation - Adds dogma or fixed beliefs

Decision Flow

  1. Submit PR: Author describes changes clearly, includes reasoning
  2. Reflection Period: Minimum 48 hours for non-urgent changes
  3. Discussion: Community discusses, asks questions
  4. Clarification: Author responds, may revise
  5. Discernment: Reviewers approve when unity emerges
  6. Merge: When required approvals reached and discussions resolved
  7. Deploy: Site automatically updates

For Contentious Changes

If strong disagreement emerges: 1. Extend discussion (1-2 weeks) 2. Seek tested experience: Has any circle tried this? 3. Identify core concern: What principle is at stake? 4. Consider alternatives: Can both concerns be addressed? 5. Sometimes: withdraw: Author may withdraw if unity isn't emerging 6. Rarely: defer: May need to wait for more practical experience

Remember: Not every idea needs to happen now. Patience is part of the practice.

Experimental Branch Process

Significant changes should be tested in practice first. Experimental branches allow testing without commitment to adoption.

When to Use Experimental Branches

  • New practice formats (online ad hoc, walking circles, etc.)
  • Changes to session structure or timing
  • Different facilitation approaches
  • New documentation methods
  • Modified governance procedures

Branch Naming Convention

experiment/[short-description]

Examples: - experiment/60min-sessions - experiment/walking-practice - experiment/async-reflections - experiment/monthly-review

10-Step Process

  1. Propose: Open GitHub issue describing experiment
  2. Create experimental branch: Fork from main, add documentation marked as experimental
  3. Document the experiment: Include rationale, testing plan, success criteria
  4. Test in practice: At least minimum number of people test for defined period
  5. Gather experience: Document what happened (reflections, challenges, insights)
  6. Hold formal review meeting: See "Formal Review Meetings" below
  7. Reach discernment: Does the meeting sense unity that this serves the practice?
  8. Submit adoption PR: Include meeting notes, participant count, consensus statement
  9. Final review: Standard PR approval process
  10. Merge or archive: Adopt to main, or keep branch for future reference with learnings

Testing Durations

  • Small experiments: 2-4 weeks minimum
  • Session structure changes: 6-12 weeks (full rotation of facilitators)
  • Major format additions: 3-6 months

Keeping Experiments Visible

Experimental branches should be: - Listed in EXPERIMENTS.md (links to branches, status, who's testing, purpose) - Marked clearly: "⚠️ Experimental - Currently being tested" - Accessible for others to review or try - Archived (not deleted) even if declined, with learnings documented

Formal Review Meetings

After testing period, hold a formal meeting to discern whether to adopt, revise, defer, or decline the experiment.

Meeting Structure

  • Testers are centered: Those with direct experience lead discussion
  • Others may attend: People who will be affected can listen, ask questions, raise concerns
  • Use Quaker-style discernment process (see DECISION_MEETING_PROTOCOL.md)
  • Experience carries weight: Those who tested speak from practice; others speak from consideration
  • Document: What happened? What did we learn? Does this serve the practice?

Why Open Meetings Matter

  • Avoids echo chamber: Testers might miss problems; outside perspectives help
  • Avoids theory over practice: Those who haven't tested shouldn't override lived experience
  • Enables learning: Observers see what testing revealed and can ask clarifying questions
  • Builds community: More people understand the change before it's adopted

Meeting Size Guidelines

Change Type Minimum Testers Who Else Should Attend
Small format tweak 3-5 people Anyone interested
Session structure change 6-10 people (one full circle) Other facilitators, affected circles
New practice format 8-15 people (multiple contexts) Representatives from all practice formats
Governance change 10-20 people All roles represented, multiple circles
Core principle change 15+ people (multiple circles) Broad representation, extended invitation

Note: Minimum numbers refer to people with direct testing experience. Others may attend to listen, question, and participate in discernment, but those who tested carry more weight in determining whether unity has been reached.

Meeting Outcomes

  1. Adopt: Unity sensed, submit PR with meeting notes
  2. Revise: Good direction, needs adjustments, continue testing
  3. Defer: Not ready, may revisit later
  4. Decline: Doesn't serve the practice, archive branch with learnings

Emergency Changes

For genuine emergencies (security issues, broken deployments, harmful content):

  1. Create the PR anyway (maintains transparency)
  2. Mark as urgent in the title and description
  3. One approval is sufficient (from any maintainer)
  4. Document in PR why urgency was needed
  5. Retrospective: Discuss how to prevent similar emergencies

Note: "I want this now" is not an emergency. Part of the practice is working with the constraint of collective review.