GitHub IssuesのModerateはまだ未提供：一般提供の見出しだけで権限を変えないで

GitHubの変更履歴で新機能を見つけたら、見出しと本文の追記を一緒に確認したい。10月28日のIssues向け「Moderate」ロールの発表には、同日付で「まだ利用できない」という更新が加わっているよ。

この記事は11月1日に確認した提供状況の整理。今日発表された機能ではなく、10月28日の発表と、その本文にある訂正を扱う。

一般提供の見出しと、本文の追記を分ける

GitHubの公式変更履歴は、タイトルを一般提供としている。一方、冒頭の追記では、Moderateはまだ利用できず、今後数週間のうちに提供されると案内している。

11月1日の確認時点でも、この追記が掲載されていた。具体的な提供日や、読者の環境で選択できることまでは確認できない。「すべての組織で、もう使える」と読み替えないようにしよう。

何のためのロールとして紹介された？

ロールは、利用者がどの操作をできるかをまとめた権限の区分。発表では、コードへのアクセス権を与えずにIssueの編集・モデレーションを行うためのModerateを紹介している。

案内された操作には、他の人が書いたIssueの編集、コメントの非表示や会話のロック、ラベル・マイルストーンの管理などがある。ただし、これは発表に記載された予定の役割の説明で、編集部が実際のModerate権限で試した結果ではないよ。

今の担当作業を、操作単位で整理しよう

組織のリポジトリロールの公式資料では、確認時点でRead・Triage・Write・Maintain・Adminの権限表が掲載されていた。

たとえば、既存ラベルの適用とラベルの新規作成では、必要な権限が同じとは限らない。担当者へ「Issue管理をお願いする」とだけ伝える代わりに、編集部では次のような確認表を作ることを提案する。

表は運用を整理するための提案であり、Moderateが使えるという確認結果ではない。権限不足の操作があるからといって、理由を確認せずWriteやAdminへ広げるのは避けたいね。

提供されたあとも、小さく確認する

まず公式発表の追記と、権限表の更新を読み直す。次に、管理者が対象組織・リポジトリで選択肢を確認し、必要な作業と不要な権限を照合する、という順番にしよう。

変更を行う場合は、元の割当を記録し、ダミーのIssueで想定した操作と制限を確認すると結果を比べやすい。選択肢がない場合は、別の権限へ自動的に置き換えず、提供状況と組織の設定を確認してね。この記事では実際の権限変更は行っていない。

リポジトリの保護ルールをまとめて変える話とは別なので、関連する作業はブランチ保護とrulesetの移行確認も読み分けよう。