Gerrit/Privilege policy/ja



権限と責任
ほとんどのウィキメディア Gerrit リポジトリは、利用者が「+2」のコード レビューを行うと、テストの実行後に Jenkins が変更を自動的にマージするように構成されています. したがって、+2 コード レビューを行う権限は、特定の Gerrit グループの人々に制限されています. 通常、各リポジトリにちなんで名付けられた Gerrit グループがあり、そのリポジトリに対する特権が付与されます. また、一部の Gerrit グループは、複数のリポジトリに対する特権を付与されます. 最も注目すべきは、 グループが、MediaWiki コア、すべての拡張機能と外装、その他の MediaWiki 関連のリポジトリに対する特権を付与されることです.

Gerrit グループは、LDAP グループからメンバーを派生させることができます. ほとんどの WMF 従業員は LDAP の  グループに属しており、これにより自動的に   グループのメンバー権限が付与されます.

Gerrit 管理者は、Gerrit グループのメンバーを追加/除去できます.

MediaWiki コアまたはウィキメディアによって展開された拡張機能への変更をマージすることは大きな問題です. 変更は、 にマージされるとすぐに、仮想化されたステージング環境である に自動的に展開されます. また、リリース ブランチがカットされる前に元に戻されない限り、次の MediaWiki コア展開ウィンドウ (展開を参照) で自動的にピック アップされます.

マージすると、ウィキペディアまたは他のサイトが機能しなくなるおそれがあります. 攻撃者がデータを削除または破損したり、個人情報にアクセスしたりすることを可能にするセキュリティの脆弱性を作成してしまうおそれがあります. そして、より一般的なケースでは、コードにテストがないか、実装が不十分であるか、社会への適応が不十分である場合、 が増加するおそれがあります. +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 などの場所を通じて会話に参加してください. 共有されたコードの所有権 (大きいか小さいかに関わらず) は、あなたの取り組みが長期的な価値を持つことを保証するのに役立ちます.



コード レビュアーが必読のページ

 * - および下位ページ
 * - および関連ページ
 * - keep this in mind when making schema changes (which should be implemented following this process)
 * - および関連ページ
 * - keep this in mind when making schema changes (which should be implemented following this process)
 * - keep this in mind when making schema changes (which should be implemented following this process)



Gerrit 特権の申請
その後、wikitech-l メーリング リストにメールを送信してください.

いずれの場合も、Phabricator のタスクには、以下が指定されている必要があります:


 * Gerrit の利用者名
 * アクセス権が必要なリポジトリ (1つ以上)
 * 作成してレビューを受けたパッチへのリンクを含む、根拠

開発者が特権リクエストにコメントする場合、申請者が高品質のパッチを提供し、+1 権限を適切に行使し、能力を示したかどうかを考慮する必要があります. ネガティブなコメントは適切に書かれ、過度に強硬にならないように注意する必要があります.

Phabricator タスクに信頼できる開発者のコンセンサスがある場合、Gerrit の管理者群のいずれかかがリクエストを解決できます. 関心を持った開発者がコメントできるように、タスクは少なくとも1週間は開いておく必要があります. リクエストが旅行や休暇期間中にオープンされている場合、追加の時間が許可されるべきです.

Phabricator でリクエストにコンセンサスがない場合、TechCom に仲裁を依頼できます.

以前は、一部の拡張機能メンテナーに、Phabricator でリクエストを行わずに新しいグループ メンバーを追加できるように、Gerrit 上の関連プロジェクトの所有権が与えられていました. このモデルは新しい拡張機能には使用しないでください. Gerrit の管理者は、通常の開発者にリポジトリ所有権を付与しないでください. 拡張機能が初めてウィキメディア クラスターにデプロイされる前に、権限を監査し、レガシーの所有権特権を +2 アクセスにダウングレードする必要があります.



信頼できる組織のための迅速なプロセス
以下の信頼できる組織からのメンバーシップの付与と失効のリクエストについては、すぐに Gerrit 管理者が対応できます:

Phabricator タスクの提出やコンセンサスの証明は必要ありません.

この機能は、採用プロセスによって信頼されたスタッフを迅速にオンボードできるようにすることを意図しています. また、信頼された組織がその組織によってよく知られており信頼できるボランティアにアクセスを許可することも可能にします.

WMF の従業員は、雇用時に LDAP の  グループに追加できます. Wikimedia Deutschland の従業員は、雇用時に LDAP の  グループに追加できます.

TechCom または CTO は、Gerrit グループに任意の人を追加するために Gerrit 管理者に指示できます.

権限の失効
Gerrit の権限を失効させることは、以下の場合に許可されます:


 * 緊急事態 (アカウントが侵害された場合など) では、Gerrit 管理者は自己の裁量で直ちにアクセス権を失効できます. Reversal of emergency revocation may be done at the administrator's discretion if the emergency is judged to have passed. TechCom, or the CTO in consultation with TechCom, may review an emergency revocation and direct its reversal.
 * Revocation of privileges of a WMF employee may be directed by that employee's manager, in consultation with WMF Talent and Culture, as discussed in the Staff Handbook.
 * Revocation of privileges from any person may be directed by TechCom, or by the CTO in consultation with TechCom.

The reasons for revocation may include:


 * Merging bad code
 * Merging your own code without review
 * Failing to socialize high impact changes within the development community
 * Not following the guidelines above
 * Inappropriate behaviour, in particular, violating the Code of Conduct
 * Termination of employment or contract

It is WMF policy to revoke all privileges when staff members depart, even if those privileges were granted prior to the beginning of employment by virtue of volunteer work. Consistent application of this policy helps to protect the privacy of departing staff members: no fault is implied. If departed staff members wish to continue to contribute in a volunteer capacity, they may reapply for access by the usual process.



権限失効の申請
Emergency revocation should be requested by directly contacting a Gerrit administrator, for example using IRC. Revocation for reasons of competence or behaviour should generally be handled in private, following a defined escalation path. For more details, refer to the following table:



この方針の修正
Amendments to this policy must be approved by the CTO, in consultation with TechCom.

定義

 * CTO : The Chief Technology Officer of the Wikimedia Foundation.
 * TechCom: The Wikimedia Technical Committee. For TechCom to decide or direct something means that a meeting of the committee, by remote audio/video conference or in person, with the attendance of a quorum of at least half of TechCom's members, passes a resolution by simple majority or unanimous consent.