Gerrit/特権方針
 | このページでは公式なウィキメディアの開発方針を記載しています。 現在、TechCom RFC process は廃止されているため、変更を加えるためのメカニズムはありません。 |
| 開発の方針 |
|---|
| 関連項目 |
| 開発の指針 |
権限と責任
ほとんどのウィキメディア Gerrit リポジトリは、利用者が「+2」のコード レビューを行うと、テストの実行後に Jenkins が変更を自動的にマージするように構成されています。
したがって、+2 コード レビューを行う権限は、特定の Gerrit グループの人々に制限されています。
通常、各リポジトリにちなんで名付けられた Gerrit グループがあり、そのリポジトリに対する特権が付与されます。
また、一部の Gerrit グループは、複数のリポジトリに対する特権を付与されます。
最も注目すべきは、mediawiki グループが、MediaWiki コア、すべての拡張機能と外装、その他の MediaWiki 関連のリポジトリに対する特権を付与されることです。
Gerrit グループは、LDAP グループからメンバーを派生させることができます。
ほとんどの WMF 従業員は LDAP の wmf グループに属しており、これにより自動的に mediawiki グループのメンバー権限が付与されます。
Gerrit 管理者は、Gerrit グループのメンバーを追加/除去できます。
MediaWiki コアまたはウィキメディアによって展開された拡張機能への変更をマージすることは大きな問題です。 変更は、Gerrit にマージされるとすぐに、仮想化されたステージング環境である ベータ クラスター に自動的に展開されます。 また、リリース ブランチがカットされる前に元に戻されない限り、次の MediaWiki コア展開ウィンドウ (展開を参照) で自動的にピック アップされます。
マージすると、ウィキペディアまたは他のサイトが機能しなくなるおそれがあります。 攻撃者がデータを削除または破損したり、個人情報にアクセスしたりすることを可能にするセキュリティの脆弱性を作成してしまうおそれがあります。 そして、より一般的なケースでは、コードにテストがないか、実装が不十分であるか、社会への適応が不十分である場合、technical debt が増加するおそれがあります。 +2 を使用する前に、この文書と関連するすべての方針を注意深くお読みください。
+2 は強い信頼の表れであり、信頼は適切な判断と慎重な行動によって維持されます。
コード レビュー、設計の議論、バグのコメントでは、+2 の権限を持つ人は、他の人の視点から見る特別な責任があります。
レビューなしでのマージ
レビューなしでコードをマージすると、コードの品質と士気が低下します。 +2 の権限のポイントは、開発とコード レビューを分離することです。 Gerrit で変更をマージする目的は、「はい、この変更が MediaWiki の規則、優れたエンジニアリング慣行に従っており、健全であることを確認しました」と世界に伝えることです。 (参照: 「Code Reviews: Just Do It」、Jeff Atwood 作。) インライン コメントを使用して、マージする前に対処する必要があるコードの問題点を示せます。
レビュアーの承認なく独自のコードをマージすると、特権が取り消される場合があります。
これは、自分が所有する Gerrit 変更に +2 を与えることと必ずしも同じではありません。 例:
- 変更がレビュー担当者から +2 を受け取ったものの、Jenkins ビルドに失敗した場合、所有者はビルド ジョブを再開するために +2 を与える必要があるかもしれません。
- 差し戻し (revert) は通常、差し戻すコミットが最近のものである限り、自己マージできます。 おそらくその時点でレビュー済のバージョンに戻っています。
- 展開ブランチ (deployment branches) とパペット リポジトリでは、変更は展開を行う人によってマージされます。この人は多くの場合、作者でもあります。 このような場合、コード レビューは通常、変更に +1 を与えることで示されます。
- Gerrit でのコミットには、所有者と修正をアップロードするレビュアー、の 2 人の作者がいる場合があります。 通常、所有者とレビュアーはそれぞれ相手の作業をレビューします。 すべての変更が確認および承認された場合に限り、コミットをマージできます。
自己マージで充分と言える些細な変更はほとんどありません。 些細な説明文書の変更や、メンテナーが 1 人だけのプロジェクトなど、場合によっては自己マージが許容されます。
ウィキメディア クラスターに展開されていない拡張機能 (およびその他のプロジェクト) の場合、コード レビューの方針は拡張機能のメンテナーまたは作者に任されています。 一部の非ウィキメディア拡張機能は、自己マージを禁止するというウィキメディアの方針に従いますが、その要件はありません。 拡張機能を作成しているのがあなただけで、変更をレビューする人がいない場合、または拡張機能が放棄された場合は、変更を自己マージできます。
チーム内レビューと共有所有権
あなたがチームの一員として作業している場合は、チームのメンバー群によるレビューが許可されるだけでなく、強く推奨されます。 メンバーに継続的にコードをレビューしてもらうことは、開発の勢いを維持し、レビュー担当者があなたのしていることに精通していることを確認するための優れた方法です。
チーム内レビューを行うときは、死角、認知バイアス、あなたが作業しているグループ以外の大きな変化に賛同する必要性に特に注意してください。 MediaWiki を含む、ほとんどのオープン ソース プロジェクトは、空想的な新しい抽象化レイヤー、外装システム、テスト フレームワークなどを作成するための放棄された努力でいっぱいです。 全体的なエコシステムに対する変更の影響を考慮し、コメントの要請、wikitech-l、IRC などの場所を通じて会話に参加してください。 共有されたコードの所有権 (大きいか小さいかに関わらず) は、あなたの取り組みが長期的な価値を持つことを保証するのに役立ちます。
コード レビュアーが必読のページ
- Code review guide
- 開発者向けセキュリティ
- Manual:コーディング規約 - および下位ページ
- Manual:単体テスト - および関連ページ
- 地域化(多言語への対応)
- Database optimization - スキーマ変更 (このプロセスに従って実装する必要がある) を行う場合は、これを念頭に置いてください
- Manual:デバッグの方法
Gerrit 特権の申請
mediawiki グループへの参加を申請する場合は、Phabricator の MediaWiki-Gerrit-Group-Requests プロジェクトに新しいタスクを作成してください。
その後、wikitech-l メーリング リストにメールを送信してください。
他のグループへの参加を申請する場合は、Phabricator の Gerrit-Privilege-Requests プロジェクトに新しいタスクを作成してください。
いずれの場合も、Phabricator のタスクには、以下が指定されている必要があります:
- Gerrit の利用者名
- アクセス権が必要なリポジトリ (1つ以上)
- 作成してレビューを受けたパッチへのリンクを含む、根拠
開発者が特権リクエストにコメントする場合、申請者が高品質のパッチを提供し、+1 権限を適切に行使し、能力を示したかどうかを考慮する必要があります。 ネガティブなコメントは適切に書かれ、過度に強硬にならないように注意する必要があります。
Phabricator タスクに信頼できる開発者のコンセンサスがある場合、Gerrit の管理者群のいずれかかがリクエストを解決できます。 関心を持った開発者がコメントできるように、タスクは少なくとも1週間は開いておく必要があります。 リクエストが旅行や休暇期間中にオープンされている場合、追加の時間が許可されるべきです。
Phabricator でリクエストにコンセンサスがない場合、TechCom に仲裁を依頼できます。
以前は、一部の拡張機能メンテナーに、Phabricator でリクエストを行わずに新しいグループ メンバーを追加できるように、Gerrit 上の関連プロジェクトの所有権が与えられていました。 このモデルは新しい拡張機能には使用しないでください。 Gerrit の管理者は、通常の開発者にリポジトリ所有権を付与しないでください。 拡張機能が初めてウィキメディア クラスターにデプロイされる前に、権限を監査し、レガシーの所有権特権を +2 アクセスにダウングレードする必要があります。
信頼できる組織のための迅速なプロセス
以下の信頼できる組織からのメンバーシップの付与と失効のリクエストについては、すぐに Gerrit 管理者が対応できます:
| 組織 | 管理するグループ |
|---|---|
| Wikimedia Deutschland | wmde, wmde-mediawiki
|
| ShoutWiki | ShoutWiki, Brickimedia
|
| Hallo Welt! | bluespice
|
| WikiTeq | WikiTeq
|
Phabricator タスクの提出やコンセンサスの証明は必要ありません。
この機能は、採用プロセスによって信頼されたスタッフを迅速にオンボードできるようにすることを意図しています。 また、信頼された組織がその組織によってよく知られており信頼できるボランティアにアクセスを許可することも可能にします。
WMF の従業員は、雇用時に LDAP の wmf グループに追加できます。
Wikimedia Deutschland の従業員は、雇用時に LDAP の wmde グループに追加できます。
TechCom または CTO は、Gerrit グループに任意の人を追加するために Gerrit 管理者に指示できます。
権限の失効
Gerrit の権限を失効させることは、以下の場合に許可されます:
- 緊急事態 (アカウントが侵害された場合など) では、Gerrit 管理者は自己の裁量で直ちにアクセス権を失効できます。 緊急事態が終了したと判断された場合、管理者は裁量に基づいて緊急の失効を元に戻せます。 TechCom、または TechCom と相談した上で CTO は、緊急の失効の再考と取り消しの撤回を指示できます。
- WMF の従業員の権限の失効は、スタッフ ハンドブックで議論されているように、WMF Talent and Culture と相談した上で、その従業員のマネージャーが指示できます。
- TechCom または、TechCom と相談した上で CTO は、任意の人物の権限の失効を指示できます。
権限の失効の理由には、以下が含まれます:
- 悪質なコードのマージ
- レビューなしに自分のコードをマージ
- 影響が大きい変更に対する開発コミュニティ内での議論不足
- 上記のガイドラインに従わない
- 適切ではない行動、特に行動規範の違反
- 雇用または契約が終了した場合
WMF の方針では、スタッフが退職した場合は、そのスタッフが就職前にボランティア活動によって与えられた特権であっても、すべての特権を失効させることになっています。 この方針を一貫して適用することで、退職するスタッフのプライバシーを保護できます。特に問題はないという意味で、責任は暗示されていません。 退職したスタッフがボランティア活動を続けたい場合は、通常の手順でアクセス権を再度申請できます。
権限失効の申請
緊急時の特権の失効は、IRC などを使用して直接 Gerrit 管理者に要請する必要があります。 能力や行動に関する特権の失効については、通常、定義されたエスカレーション経路に従って個別に処理されるべきです。 詳細は以下の表を参照してください:
| シナリオ | 操作 |
|---|---|
|
|
|
|
|
|
この方針の修正
この方針の改定には、TechCom と協議して CTO が承認する必要があります。
定義
- CTO
- ウィキメディア財団の最高技術責任者 (Chief Technology Officer)。
- TechCom
- ウィキメディアの技術委員会 (Wikimedia Technical Committee)。 TechCom が何かを決定または指示する場合、TechCom の半数以上のクオーラムが出席した音声/ビデオ会議や対面会議で、賛成多数または全会一致で決議が採択されたことを意味します。