初期ガバナンスプロセス

正本文書: proposals/ja/0001-initial-governance-process.md / 編集を提案

Summary

World Foundation Designの初期運営では、Issue、Proposal、Pull Request、Review、Merge、Decision、必要に応じたReviewまたはRollbackを使った軽量なガバナンスプロセスを採用する。

初期段階では参加者数が少ないため、過剰な投票制度や複雑な承認フローは導入しない。ただし、重要な判断理由は記録し、後から検証・改善・フォークできる状態を保つ。

Problem

このリポジトリは社会設計リポジトリであり、単なる文章置き場ではない。

思想、用語、原則、モジュール責任、移行方針などの変更は、後の設計全体に影響する。その一方で、初期から複雑な制度を入れすぎると、参加者が提案しづらくなり、議論速度が落ちる。

必要なのは、初期参加者が迷わず使える軽量な手続きと、重要な判断を失わない記録方法である。

Motivation

このProposalは、次の目的を持つ。

変更の入口を明確にする
重要な判断理由を残す
レビュー可能な形で設計を進める
権限集中や密室判断を避ける
将来のメンテナー制度、投票制度、Decision Processへ拡張しやすくする

Proposed Change

初期ガバナンスプロセスとして、次の運用を採用する。

Issue
↓
必要ならProposal
↓
Pull Request
↓
Review
↓
Merge
↓
重要判断はDecisionへ記録
↓
必要なら後日ReviewまたはRollback

変更の種類

1. 軽微な変更

誤字修正、リンク修正、表現の明確化、構造を変えない補足などは、Pull Requestで直接提案できる。

2. 通常の設計変更

docs、modules、glossary、researchの内容を変更する場合は、Pull Requestで提案し、レビューで理由と影響を確認する。

3. 重要な設計変更

以下に関わる変更は、原則としてProposalを作成する。

Vision
Principles
Architecture
モジュール責任範囲
Glossaryの重要用語
Non-goals
Safety
Threat Model
Governance Process
EconomyやWelfareの運用原則
離脱可能性、フォーク可能性、透明性に影響する変更

4. 意思決定の記録

重要なProposalを採用、却下、保留、または置き換える場合は、Decisionとして記録する。

Decisionには、結論だけでなく、背景、理由、代替案、影響を残す。

Issueの使い分け

Idea: 新しいアイデア
Problem: 問題、矛盾、リスク
Proposal: 設計変更の提案
Translation: 翻訳、用語、多言語対応

Issueは必ずしも完成された提案である必要はない。違和感、懸念、未整理の問いも歓迎する。

Pull Requestの使い方

Pull Requestでは、次の観点を確認する。

特定名称や組織を一元的な統制主体のように見せていないか
自由参加、離脱可能性、透明性に反していないか
用語集と矛盾していないか
悪用ケースや腐敗リスクを検討したか
支配、強制、違法回避、カルト化、監視強化、離脱不能性につながっていないか
Non-goals、Safety、Threat Modelへの影響を確認したか
重大なリスクがある場合、Threat Modelを更新したか
後から問題が出た場合のRollback Planを確認したか
日本語正本と英語版の関係を壊していないか
翻訳に影響する場合、Translation Issueを作る必要があるか
重要な判断がDecisionとして残されるべきか

初期メンテナーの役割

初期メンテナーは、支配的な権限者ではなく、リポジトリの品質と議論の流れを維持する責任を持つ。

主な役割は次の通り。

IssueとPull Requestの整理
明らかな荒らしやスパムへの対応
用語の一貫性確認
重要な判断のDecision化の促進
レビュー観点の提示
新規参加者が迷わない導線づくり

Affected Documents or Modules

GOVERNANCE.md
CONTRIBUTING.md
.github/ISSUE_TEMPLATE/
.github/PULL_REQUEST_TEMPLATE.md
proposals/
decisions/
modules/ja/governance/README.md

Benefits

初期参加者が提案しやすくなる
重要な判断理由が失われにくくなる
軽量さと透明性を両立しやすくなる
将来の制度拡張に接続しやすくなる
フォーク可能性とレビュー可能性を保ちやすくなる

Risks

ProposalやDecisionが増えすぎると運用が重くなる
初期メンテナーの判断に依存しすぎる可能性がある
重要変更と軽微変更の境界が曖昧になる可能性がある
議論が長期化し、変更速度が落ちる可能性がある

Abuse Cases

複雑な手続きを理由に、参加者の提案を止める
メンテナーが「軽微な変更」として重要な変更を通す
Decisionに都合のよい理由だけを書く
Proposalを大量に作り、議論を進めにくくする
用語集を使って思想の幅を狭めすぎる

Alternatives

すべてPull Requestだけで進める

初期速度は速いが、重要な判断理由が散らばりやすい。

最初から厳密な投票制度を導入する

透明性は高まる可能性があるが、初期参加者が少ない段階では運用が重く、形式だけが先行しやすい。

メンテナー判断だけで進める

速度は速いが、この設計が重視する透明性、離脱可能性、腐敗耐性と衝突しやすい。

Open Questions

何人以上の参加者からメンテナー制度を明文化するか
Proposalの採用条件をいつ定義するか
Decisionの翻訳優先度をどう決めるか
異議申し立ての正式手続きはいつ追加するか
投票制度を導入する場合、誰にどの範囲の投票権を与えるか