要約

  • W3C Math Working Groupでは、対面会議または電話会議の決議は、公開決定を含めてすべて暫定であり、CfCを通過して初めて作業部会の決定になる。
  • CfCの応答期間は、議長による合意評価に応じるとの留保付きで1週間。期限までに異議が出なければ、憲章上は合意した決議とみなされる。
  • 憲章が従うW3C Processでは、合意は「相当数の支持」と「持続する異議がないこと」の組み合わせであり、無言の参加者は支持者ではなく棄権者である。
  • 公開メーリングリストやGitHubは技術的証拠を広く受け取る場所だが、作業部会の意思決定資格を一般公開する仕組みではない。
  • 提案の版、資格者の集合、通知、期間、積極的支持、棄権、異議処理、議長判断、再審議を一つに結ぶ「合意の受領票」があれば、柔軟な運営を投票制に変えずに検証可能にできる。

暫定という一語が守っているもの

会議は参加できた人に有利だ。時差が合う人、即座に発言できる人、その場で所属組織に確認する必要のない人ほど、決議形成に参加しやすい。W3C Math Working Groupの憲章は、この偏りを会議後の手続で補う。

対面会議や電話会議で採択された決議は、公開に関する決議であっても暫定にとどまる。電子メール、GitHub issue、ウェブ調査などでCfCを発行し、原則1週間の応答期間を設ける。期間末まで異議がなければ、決議は作業部会の合意を得たものとなる。

この設計は会議を無効にするのではない。会議は提案を練り、争点を可視化し、暫定的な方向を定める。CfCは、その方向を会議にいなかった有資格者にも提示し、組織内協議や実装確認の時間を与える。会議録が「その場で何が決まったか」を示し、CfCが「より広い資格者集合がそれを作業部会の決定にできたか」を示す。

したがって、暫定決議の日時と最終決定の日時は別の状態遷移である。一つの「採択済み」表示にまとめると、1週間を置いた制度上の理由が消えてしまう。

反対ゼロは、支持の数を答えない

憲章の文だけを見ると閉鎖条件は明快だ。期限まで異議がなければ合意とみなす。だが、同じ憲章はW3C Processとの衝突時にはProcessを優先すると明記し、合意の節そのものがProcessを参照している。

2025年8月18日版のProcessは、資格者集合の相当数が決定を支持し、持続する異議が誰からも出ていない状態を合意と定義する。さらに、意見なしと明示することも、何も言わないことも棄権であるとする。

ここには二つの問いがある。

  1. 持続する異議は残っているか。
  2. 積極的な支持は相当数あるか。

無応答は第一の問いに対して異議を増やさない。しかし第二の問いに支持を一票足すこともない。異議ゼロという観測値を、支持が十分という別の観測値にコピーしてはならない。

Processは、十分な告知後の異議なしを同意として扱う「lazy consensus」も認めている。これは小規模な専門家集団が日常的な判断ごとに全員回答を待たないための重要な柔軟性だ。それでもProcessは、支持が少なく棄権が多い「広範な無関心」を避けるため、積極的支持の最低基準を各グループが設定するよう勧めている。全W3C共通の割合や定足数は定めていない。

つまり、1週間のCfCは正当な手段であり、沈黙は棄権であり、最終的に支持が十分かを議長が判断する。この三点は同時に成立する。

数字を固定しないなら、判断を記録する

Math憲章は、活動期間を通じて6人以上の活発な参加者を期待し、主要な実装者、編集者、テスト責任者の参加を挙げる。ただし、これは各決定の定足数ではない。憲章のCfC条項には、数値の支持基準も定足数も追加されていない。

固定しないことには理由がある。誤植修正、草案公開、APIの挙動に影響する仕様変更では、必要な関与の質が違う。毎回同じ数字を要求すれば、少人数グループは予定の衝突だけで止まるかもしれない。

その代わり、裁量の使い方が見える必要がある。「異議は届かなかった」という文だけでは、資格者が何人いたか、全員に通知されたか、積極的支持が何件あったか、明示的棄権と無応答がどれだけあったかが分からない。議長が幅広い関与を確認したのか、空の受信箱を閉じただけなのかも区別できない。

Lu HengのいうPolicy Mirrorとして憲章を読むと、重要なのは制度が自らの権力をどこで発生させると考えているかである。Math憲章では、会議の発言だけでも、タイマーだけでもない。議論、非同期の通知、異議、支持、そして議長の評価が決定を作る。その構造を記録側も映すべきだ。

公開の証拠面と、限定された決定集合

W3C Math Working Groupの技術作業は公開性が高い。会議録は公開審査用に保管され、技術的議論とissue trackingは一般の人も読み書きできる形で行われる。www-mathメーリングリストとGitHubが主要な場所で、非参加者の技術貢献も歓迎される。

一方、会議自体は一般参加に開かれていない。Processが既定で意思決定資格を与える集合は、そのグループの参加者である。外部の研究者が重要な不具合を示せば、議長は正当な意見として考慮すべきだが、その人が自動的にグループ合意の構成員になるわけではない。逆に、正式参加者であっても沈黙したなら、記録上は支持ではなく棄権である。

そこで、記録には二つの層が要る。証拠層は外部を含むコメント、テスト、代案、異議を保存する。決定層は資格者の集合と、その中での支持・棄権・持続異議に関する議長評価を保存する。

この区別は排除ではない。外部意見を資格の欠如だけで退ける誤りと、公開issueへの投稿を全世界からの委任と見せる誤りを同時に防ぐ。公開性は訂正能力を増やす。誰を代表して決めるかという問いを消すものではない。

議長の決定権を、機械的集計に置き換えない

Processでは、議長自身の判断によるchair decisionと、グループの合意を評価して議長が記録するgroup decisionは別である。CfCの閉鎖は後者だ。締切を過ぎた瞬間にシステムが自動で合意を生成するのではない。

異議には強弱がある。受け入れ可能な不一致と、技術的根拠を伴う持続異議は同じではない。同一組織の複数人が同じ立場を示す場合もある。会議後に初めて得られた実装結果なら、遅いというだけで価値を失わない。これらは単純集計より議長判断に向く。

だからこそ、判断の痕跡が要る。CfCを閉じる記録は、対象の正確な版、支持の存在、異議の処理、議長が認定した状態を示すべきだ。投票に移るなら、Processが要求する通り、争点、投票を行う判断、結果、Formal Objectionを残す。新情報で再開するなら、元の決定を削除せず、後続決定との系譜を作る。

プライベートな連絡先やMember-onlyの内容を公開する必要はない。公開可能な最小状態だけでも、期限切れと合意評価の違いは示せる。

合意の受領票をどう作るか

受領票の先頭には、決議文と版を置く。文書URLだけでなく、コミット、スナップショット、公開候補など、何が審査対象だったかを固定する。期間中に実質的変更が入った場合は、同じCfCを継続したのか、新しいCfCが必要だったのかを記す。

次に、資格者集合の定義と人数、通知に使った正式チャネル、開始・終了時刻、通常の1週間から変更したかを記録する。個人データを公開せずとも分母は示せる。

応答は、支持、明示的棄権、沈黙、受け入れ可能な不一致、持続異議に分ける。外部コメントは別の証拠欄に入れ、無視も票への変換もしない。実質的異議には、回答、変更差分、変更しない理由、Formal Objectionの状態を接続する。

最後に、閉鎖した議長、時刻、評価結果、成立した正確な決議を記す。後に新情報が出たら、再開理由と後継記録を加える。履歴は訂正されても消去されない。

WCAG Working Groupが公開した手続には、会議決議はCfCを代替しないこと、関連議論をリンクすること、異議により再議論し得ること、正式決定を別ページに記録することが書かれている。この文書は古く、W3C全体の合意を表すとは限らないと自ら断っており、Mathを拘束しない。ただし、W3Cの実務内で提案から決定までの連結記録を作れることは示している。

証拠の限界

調査した公開資料からは、特定のMath CfCが支持不足だった、通知を欠いた、異議を誤処理した、不適切に閉じた、という事実は確認できない。本稿は公開された制度設計を読むもので、個別決定の監査ではない。

沈黙に拒否権を与える主張でもない。合意は全会一致ではなく、棄権があってよい。持続異議が残っても、十分に検討した後に前進できる場合があり、行き詰まりには投票も用意されている。

確認できるのは、憲章が異議なしを1週間後の転換条件とし、上位Processが沈黙を棄権、合意を相当数の支持と持続異議なしの組み合わせとしていることだ。受領票は新しい拒否権ではない。この二つを同じ履歴に保存するだけである。

出典

  1. Lu Heng, “The Policy Mirror”
  2. Lu Heng, “The Multi-Stakeholder Mirage”
  3. W3C, Math Working Group Charter (2026)
  4. W3C Process Document, 18 August 2025
  5. W3C, Math Working Group public group page
  6. W3C Math home page
  7. W3C, Working/Interest Group Chair guide
  8. W3C, “W3C updates its Process Document”
  9. WCAG Working Group Consensus Procedure