要約

  • CPC憲章は、2026年秋の選挙サイクルから、非Impactプロジェクト代表とRegular Member代表を、最大五席のCommunity Voting Memberへ統合すると定める。
  • Observer、Regular Member、選挙人、Voting Memberは同じ地位ではない。Community Voting Member候補はRegular Memberであり、かつImpact Projectの投票代表を兼ねてはならない。選挙人はImpact Project Voting MembersとRegular Membersである。
  • 移行記録は旧席の終結、新区分、適格性、選挙人数、結果、雇用主集中の確認、Board・CPC・各プロジェクトの権限を別々に残すべきである。予定を結果として書いたり、内部選挙をJavaScript全体の委任と呼んだりしてはならない。

予定表にある制度と、成立した構成は違う

オープンソース組織では、制度文書が実際の出来事より先に公開される。憲章に新しい区分が載り、会議に傍聴者が参加でき、リポジトリに将来の席名が表示される。どれも意味のある事実だが、投票が始まったこと、候補の資格が確認されたこと、集計が終わったこと、特定の人が就任したことの証明ではない。

OpenJSの憲章は役割を分けている。CPCはFoundationの技術的リーダーシップであり、Boardは事業上のリーダーシップである。BoardはCPCの総合方針を置き、CPCはその範囲で委任された技術的な仕事を担う。さらに憲章は、2026年秋から従来の二つの非Impact投票経路をCommunity Voting Memberへ移すと明記する。

この文言が支持するのは、予定された制度変更である。公開資料は、候補募集がすでに始まった、投票用名簿が確定した、五席が満たされた、あるいは個人が新たな席に座った、とは示していない。未来形のルールを完了した選挙として扱えば、証拠と予測を混同することになる。

移行後に必要なのは、内部の記憶に頼らない照合可能性である。以前の代表は任期を終えたのか、辞任したのか、交代したのか、Regular Memberに戻ったのか、新しい席に立候補したのか。五つまで許される席のうち何席が実際に埋まったのか。投票時点でImpact Project Voting MembersとRegular Membersはそれぞれ何人だったのか。同じ雇用主への所属を全Voting Membersの四分の一以下にする条件は、どの分母で検査されたのか。ある判断はBoard、CPC、それとも自律したプロジェクトのどこに属するのか。

これは不正を示唆する質問ではない。後から更新された名簿を、根拠のない権限移転の物語にしないための、最小限の記録項目である。

「コミュニティ」の中にある四つの位置

憲章はObservers、Regular Members、Voting Membersを区別する。CPCの公開リポジトリは非会員のObserver参加を認める。ガバナンス文書は、最近かつ継続的にOpenJSで活動した協力者がRegular Memberを申請する道を定める。Community Voting Member選挙の有権者はさらに限定され、Impact Project Voting MembersとRegular Membersで構成される。

Observer は公開会合に出席し、合意形成に参加できる。これは本物の参加だが、投票名簿への登録や席の保有を意味しない。

Regular Member はより狭い組織上の資格である。プロジェクト、コミュニティ、協働空間またはCPCの仕事における最近の継続活動が必要で、審査手続がある。この資格は候補要件であり有権者区分でもある。しかし、資格があるだけで当選は証明されない。

Impact Project Voting Member は別の出所を持つ。Impact Projectは自身の手続で最大二人を指名できる。新制度でもこの区分は残る。その人たちがCommunity Voting Member選挙に参加しても、彼ら自身の席の出所は消えない。

Community Voting Member は秋のサイクルに向けて定義された投票区分で、上限は五席である。候補者はRegular Memberで、Impact Projectの投票代表ではないことが必要だ。「コミュニティが選んだ」という短い表現は、誰が会合にいたか、誰がRegular Memberか、誰が投票できたか、誰が席を得たかという四つの別の事実を潰してしまう。憲章は区分を先に示す。選挙結果は残りの事実を示さなければならない。

ここで卢恒の多利益関係者論が役立つ。参加は知識、警告、反対意見をもたらすが、それだけで全ての影響を受ける者を拘束する本人権限にはならない。公開会合や内部選挙は、Foundation内部で定義された手続の証拠であり、JavaScript生態系全体からの包括的委任の証拠ではない。

新しい席は他の権限を吸収しない

投票区分の変更は、CPCを囲む全ての権限を変更しない。Voting Membersは憲章がCPCに与える最終判断を担う。CPCはまずlazy consensusを求め、異議を解けない場合に定められた投票手続を使う。Boardは総合方針、特に法的な領域の権限、憲章変更の承認を保つ。各プロジェクトはCPCの指針内で、独自に文書化された技術決定過程を保つ。

層には接点があるが同一ではない。CPC Directorはプロジェクトと関連コミュニティをBoardに代表できる。プロジェクト憲章の変更にはCPCの承認が必要なことがある。技術課題はBoardへ上げる場合がある。しかしCommunity Voting Memberが自動的にBoard Director、全メンテナーの代表、各プロジェクトの内部決定者になるわけではない。移行記録は実際の資格を名指しすべきである。

現在のガバナンスには既に記録の面がある。候補期間初日の公開issue、選挙後のREADME更新pull request、非公開の結果通知、議題、会合資料である。人事、法務、Board情報の一部には正当な非公開範囲もある。透明性は私的資料をすべて公開することではなく、決定的な公開事実をつなぐことである。

READMEに新しい名前があるだけでは、任期、旧席の終結、選挙人の分母は分からない。ガバナンス文書は、任期を終えたVoting Memberが別段の意思表示がなければRegular Memberになるとする。これは役立つ既定状態だが、個人の退出記録そのものではない。「最大五」も、特定の周期に何席を埋めたかを示さない。四分の一の雇用主制限も、日付入りの全体人数と所属の基準なしには再現できない。

Community Voting Member移行記録

Daniel Kadeは簡潔な Community Voting Member移行記録 を提案する。これは憲章を書き換えず、私的な候補資料の開示を求めない。issue、議題、名簿、リポジトリ更新に散る重要な公開事実を結ぶものだ。

第一は サイクル状態 である。「予定された移行」「候補募集」「投票中」「結果確定」「訂正」を明示し、支配的な憲章文言と新旧の席区分へリンクする。これにより未来の規則を完了した任命として読まない。

第二は 席位地図 である。影響を受ける旧経路ごとに、席の出所、公表された保有者、通常の任期境界、任期満了・辞任・交代・Regular Memberのみへの移行・新席への立候補・非公表という終了状態を残す。新しい五席については、充足、空席、未公表を区別する。名前がないことを空席の証拠にしてはならない。

第三は 資格と選挙人 である。候補条件と二つの有権者区分を記し、日付入りの人数か保持された監査方法を示す。全個人の私的な資格理由を公開する必要はないが、結果の分母は理解可能でなければならない。

第四は 手続と結果 をつなぐ。候補issue、公開されるなら実際の選挙方式、結果通知、READMEのpull request、発効日、結果としてのVoting Member名簿である。憲章はCondorcetや単記移譲式投票を選択肢として挙げるが、特定の周期でどちらを使ったかを推定してはならない。

第五は 構成制約の確認 である。発効日におけるVoting Members総数、公表可能な雇用主所属の根拠、四分の一上限、そして適合・是正済み・保留・非公表という状態を示す。これは憲章上の条件を検証する行為であり、利益相反を告発するものではない。

最後は 権限境界と訂正履歴 である。Board、CPC、CPC Directors、プロジェクト自治を分け、公開資料が示さない私的資格理由、非公表票数、後の辞任、Boardの決定を明記する。訂正は、名簿を黙って上書きするのではなく、日付のある追記になる。

開かれたガバナンスは、全参加者が全権限を持つという意味ではない。実在する権限に、見える出所、範囲、終了状態があるという意味である。OpenJSには、秋の移行と同時にその区別を残す機会がある。

参考資料

  1. OpenJS Cross Project Council Charter
  2. OpenJS Cross Project Council Governance
  3. OpenJS Cross Project Council repository and current roster
  4. OpenJS Foundation Governance archive
  5. Lu Heng — The Multi-Stakeholder Mirage