GOVERNANCE.adoc

Governance Model

Table of Contents

• Overview
• Decision-Making Structure
  • Perimeter 1: Core (Benevolent Dictatorship)
  • Perimeter 2: Extensions (Maintainer Review)
  • Perimeter 3: Community (Open Contribution)
• Roles and Responsibilities
  • Core Maintainers
  • Trusted Contributors
  • Community Contributors
• Conflict Resolution
  • Technical Disagreements
  • Interpersonal Conflicts
• Succession Planning
  • Adding Core Maintainers
  • Removing Core Maintainers
  • Project Continuity
• Financial Governance
• Release Management
  • Versioning
  • Release Process
  • Release Cadence
• Intellectual Property
  • Copyright
  • Patents
• Code of Conduct Enforcement
• Amendment Process
• Transparency
  • Public
  • Private
• Communication Channels
• Values and Principles
• Acknowledgment

Overview

Valence Shell follows a Tri-Perimeter Governance Model aligned with the TPCF (Tri-Perimeter Contribution Framework).

Decision-Making Structure

Perimeter 1: Core (Benevolent Dictatorship)

Scope: Formal proofs, security-critical code, foundational architecture

Decision Makers: Project maintainers with formal verification expertise

Process: . Proposal via RFC (Request for Comments) . Technical review by all core maintainers . Proof verification . Consensus required (all maintainers must approve) . Implementation with tests . Final review before merge

Timeline: 2-4 weeks minimum for major changes

Perimeter 2: Extensions (Maintainer Review)

Scope: Implementations, features, optimizations

Decision Makers: Project maintainers + trusted contributors

Process: . Feature proposal via GitHub/GitLab issue . Design discussion . Implementation by contributor . Code review by at least 1 maintainer . CI/CD must pass . Merge with maintainer approval

Timeline: 1-2 weeks for typical features

Perimeter 3: Community (Open Contribution)

Scope: Examples, tutorials, documentation, tools

Decision Makers: Any maintainer can approve

Process: . Submit pull/merge request . Self-document the contribution . Basic tests pass . Quick review by any maintainer . Merge

Timeline: 1-3 days

Roles and Responsibilities

Core Maintainers

Responsibilities:

• Maintain formal proofs

• Review security-critical changes

• Set technical direction

• Manage releases

• Enforce Code of Conduct

• Respond to security issues

Requirements:

• Formal verification expertise (Coq/Lean/Agda/Isabelle)

• 2+ years in formal methods

• Commitment to project values

• Active participation

Current: See MAINTAINERS.adoc

Trusted Contributors

Responsibilities:

• Implement features per specifications

• Review community contributions

• Help newcomers

• Maintain test coverage

• Update documentation

Path to Becoming:

1. 5+ quality contributions to Perimeter 3

2. Demonstrate understanding of formal specifications

3. Follow coding standards

4. Help community members

5. Nomination by core maintainer

6. Majority vote of existing maintainers

Community Contributors

Responsibilities:

• Follow Code of Conduct

• Test contributions

• Document work

• Help others when possible

How to Start:

1. Read CONTRIBUTING.md

2. Find good-first-issue tag

3. Submit PR to Perimeter 3

4. Iterate based on feedback

Conflict Resolution

Technical Disagreements

1. Discussion in GitHub/GitLab issue

2. Present evidence (benchmarks, formal proofs, citations)

3. Seek consensus

4. If no consensus: Core maintainers vote

5. Benevolent dictator (project lead) breaks ties

6. Document decision rationale

Interpersonal Conflicts

1. Follow CODE_OF_CONDUCT.md

2. Private discussion first

3. Escalate to maintainers if needed

4. Formal Code of Conduct process

5. Appeals process available

Succession Planning

Adding Core Maintainers

Process:

1. Nomination by existing core maintainer

2. Must have:

   • Formal verification expertise

   • 1+ year as trusted contributor

   • Significant proof contributions

   • Community respect

3. Discussion period (2 weeks)

4. Consensus vote (all core maintainers must approve)

5. Public announcement

Removing Core Maintainers

Scenarios:

• Voluntary: Maintainer steps down (honored in MAINTAINERS.adoc as emeritus)

• Inactivity: No activity for 6+ months (gentle inquiry first)

• Code of Conduct violation: Per enforcement process

Process: Consensus of remaining core maintainers

Project Continuity

1. All knowledge documented (not in heads)

2. Proofs are self-documenting

3. Regular succession planning discussions

4. Bus factor mitigation (train multiple maintainers)

5. Emergency contact: See SECURITY.md

Financial Governance

Current Status: Unfunded research project

If Funded:

1. Transparent budgeting

2. Quarterly financial reports

3. OpenCollective or similar (public ledger)

4. Spending decisions: Core maintainers consensus

5. No profit motive (solidarity economics)

Release Management

Versioning

1. Semantic Versioning 2.0

2. Major.Minor.Patch (e.g., 0.5.0)

3. Pre-1.0: Research prototype

4. 1.0+: Production-ready (after extraction gap closed)

Release Process

1. Version bump in CHANGELOG.adoc

2. Tag commit: git tag -a v0.x.x

3. CI/CD runs full verification

4. All proofs must compile

5. All tests must pass

6. Security audit (for major versions)

7. Announce on GitHub/GitLab

8. Update documentation

Release Cadence

• Minor releases: Every 2-3 months (when features ready)

• Patch releases: As needed for critical fixes

• Major releases: When architecture changes

Intellectual Property

Copyright

1. Contributors retain copyright

2. License: Palimpsest-MPL 1.0 or later (see LICENSE)

3. No copyright assignment required

4. Attribution preserved (Palimpsest requirement)

Patents

1. No patent trolling

2. If contributor holds patents on contributed code, grant royalty-free license

3. Defensive patent use only

Code of Conduct Enforcement

See CODE_OF_CONDUCT.md for full details.

Enforcement Team:

• Core maintainers

• Can designate CoC officers

Process:

1. Report received (confidential)

2. Investigation (1-2 weeks)

3. Decision: Correction, Warning, Temporary Ban, Permanent Ban

4. Appeals process available

Amendment Process

Changing This Governance Document:

1. Proposal via GitHub/GitLab issue

2. Discussion period (4 weeks minimum)

3. Consensus of core maintainers

4. Update GOVERNANCE.adoc

5. Announce changes publicly

Transparency

Public

• Decisions and rationale

• Release plans and roadmap

• Security advisories

• Code of Conduct enforcement statistics (anonymized)

• Financial information (if funded)

Private

• Security vulnerabilities (until fixed)

• Code of Conduct reports (unless reporter requests public)

• Personnel matters

• Pre-decision discussions (working drafts)

Communication Channels

• Public discussion: GitHub/GitLab issues

• Security issues: See SECURITY.md

• Code of Conduct: See CODE_OF_CONDUCT.md

• General email: See MAINTAINERS.adoc

Values and Principles

1. Formal correctness over speed

2. Mathematical guarantees over testing alone

3. Transparency over secrecy

4. Community over ego

5. Documentation over oral tradition

6. Reproducibility over "works on my machine"

7. Emotional safety alongside technical rigor

Acknowledgment

This governance model is inspired by:

• Rust Project governance

• Python PEPs (Enhancement Proposals)

• Apache Software Foundation

• Contributor Covenant

---

Last Updated: 2025-11-22
Version: 1.0
Maintainer: See MAINTAINERS.adoc