要約

  • 現在の公開ファイルにはproject-maintainersが162アカウント、servicedeskが19アカウントある。Community Managementに載る2人は前者に含まれ、後者にはいない。
  • Governance Committee CharterはCommunity ManagersにService Deskアクセスを約束する。10月30日の同期ルールは、アクセス用グループを二委員会の名簿から作る。CNCFへの手動申請がこの役職にもアクセスを与えるか、公開資料は説明していない。

分析

役職を任命する憲章、アクセスを配る同期式

会議を動かし、SIGをまたいで施策をつなぎ、CNCFと連絡を取るCommunity Managersにとって、Service Deskは実務の窓口だ。憲章はそのアクセスを認めるが、自動名簿は委員会所属を条件にする。今公表されている二人は、19人の名簿から外れている。

同日にマージされた同期プルリクエストは、公開メンバーデータを元に名簿を作る。生成式は単純だ。project-maintainersにはGovernance Committee、Technical Committee、maintainersの3区分を入れる。servicedeskには二つの委員会だけを入れる。入力する役職が違えば、自動で付くアクセスも違う。

2月に更新されたGovernance Committee Charterは、コミュニティ横断の役割としてCommunity Managersを置く。Governance Committeeは1年任期で任命し、プロジェクト外からも選べる。CNCFや加盟組織との連絡、イベント、コミュニティ施策を担い、Service Deskアクセスを持つ。

公開メンバー一覧には、現在2人がCommunity Managementとして載る。現行の.project名簿では、2人のGitHub handleは162人のproject-maintainersにあり、19人のservicedeskにはない。

CNCFの9月のプロジェクト報告は、servicedeskグループがなければ全maintainersがアクセスを保つと説明する。グループを設定すると、記載されたhandleだけがアクセスでき、その全員がproject-maintainersにも入っていなければならない。OpenTelemetryはこの範囲指定を初めて使った。メーリングリストは今も全maintainersに開かれている。変わるのはサポート窓口の範囲だ。

憲章は職務で権利を決め、同期式は委員会所属でアクセスを選ぶ。現在の2人はmaintainersでもあるが、その分類だけでは19人の自動対象に入らない。

空のチーム向け安全弁では足りない

CNCFの.project自動化ガイドは、servicedeskが空、または誰も解決できない場合、警告を出して既存アクセスを維持する。誤記が全員の席を消す事態を防ぐ設計だ。

OpenTelemetryのグループは埋まっており、生成式も動く。空データ向けの安全弁は、正しい形式のリストが憲章上の役職を抜かした場合を扱わない。形式検査を通っても、権利と付与対象は食い違ったままだ。

Community Managersは複数SIGの活動やCNCFとの調整を担う。業務で支援依頼が必要なら、アクセスはその役職が仕事を進める手段になる。任命と監督を担う委員会は、役職とアカウントの経路を同じ運用規則に記録できる。

役職からアクセスまでを一つの記録に

OpenTelemetryはService Deskを162人全員に広げなくてよい。公開ルールに4点を結べばよい。どの役職にアクセスを与えるか。各役職をどの名簿から拾うか。手動例外は誰が承認するか。文書が食い違うとき、どちらを優先するか。

解決策は三つある。Community Managementを自動生成の対象に加える。19人のチームを保ちつつ、憲章の権利を保証する手動例外を明記する。あるいはGovernance Committeeが役割を見直し、憲章のアクセス権を正式に変更する。何も書かなければ、アカウントを作る側の仕組みが、憲章とは別の答えを事実上選ぶ。

CNCFは答えをグループ生成規則と並べて公開し、次の任命者が職務に対応するアクセス経路を確認できるようにすべきだ。

次の名簿同期で確かめるべきなのは人数だけではない。Community Managementの権利がどの経路でアカウントになるかも、同じ公開記録に残す必要がある。

出典