Gerrit/特権方針
このページでは公式なウィキメディアの開発方針を記載しています。 変更は TechCom の RFC プロセスを経て反映されます。 |
権限と責任
ほとんどのウィキメディア 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 人だけのプロジェクトなど、場合によっては自己マージが許容されます。
ウィキメディア クラスターに展開されていない拡張機能 (およびその他のプロジェクト) の場合、コード レビューの方針は拡張機能のメンテナーまたは作者に任されています。 一部の非ウィキメディア拡張機能は、自己マージを禁止するというウィキメディアの方針に従いますが、その要件はありません。 拡張機能を作成しているのがあなただけで、変更をレビューする人がいない場合、または拡張機能が放棄された場合は、変更を自己マージできます。
チーム内レビューと共有所有権
あなたがチームの一員として作業している場合は、チームのメンバー群によるレビューが許可されるだけでなく、強く推奨されます。 メンバーに継続的にコードをレビューしてもらうことは、開発の勢いを維持し、レビュー担当者があなたのしていることに精通していることを確認するための優れた方法です。
チーム内レビューを行うときは、死角、認知バイアス、あなたが作業しているグループ以外の大きな変化に賛同する必要性に特に注意してください。 Most open source projects, including MediaWiki, are full of abandoned efforts to create fancy new abstraction layers, skinning systems, testing frameworks, etc. Consider the impact of your changes on the ecosystem as a whole, and engage in conversations through requests for comment, wikitech-l, IRC and other venues. Shared ownership of code (to a greater or lesser degree) helps to ensure that what you're doing has lasting long term value.
コード レビュアーが必読のページ
- Code review guide
- 開発者向けセキュリティ
- Manual:コーディング規約 - および下位ページ
- Manual:単体テスト - および関連ページ
- 地域化(多言語への対応)
- Database optimization - keep this in mind when making schema changes (which should be implemented following this process)
- Manual:デバッグの方法
Gerrit 特権の申請
To request membership in the mediawiki group, create a new task under the MediaWiki-Gerrit-Group-Requests project in Phabricator.
Then send an email to the wikitech-l mailing list.
To request membership in another group, create a new task under the Gerrit-Privilege-Requests project in Phabricator.
In either case, the Phabricator task should specify:
- Gerrit username
- repository or repositories to which access is required
- reasoning, including links to patches written and reviewed
Developers commenting on a privilege request should consider whether the applicant has contributed high quality patches, has exercised +1 rights well, and has demonstrated competence. Negative comments should be written with tact, they should not be overly strident.
If there is a consensus of trusted developers on the Phabricator task, any of the Gerrit administrators can resolve the request. The task must remain open for at least a week, to allow interested developers to comment. Additional time should be allowed if the request is open during travel or holiday periods.
If there is no consensus on a request in Phabricator, it may be referred to TechCom for adjudication.
Previously, some extension maintainers were given ownership rights on the relevant project in Gerrit, so that they could add new group members without making a request in Phabricator. This model should not be used for new extensions. Gerrit administrators should not grant repository ownership to ordinary developers. Before an extension is deployed to the Wikimedia cluster for the first time, the rights should be audited, and legacy ownership privileges should be downgraded to +2 access.
信頼できる組織のための迅速なプロセス
Gerrit administrators may immediately act on requests from the following trusted organisations for the granting and revocation of related groups, specifically:
| 組織 | 管理するグループ |
|---|---|
| Wikimedia Deutschland | wmde, wmde-mediawiki
|
| ShoutWiki | ShoutWiki, Brickimedia
|
| Hallo Welt! | bluespice
|
| WikiTeq | WikiTeq
|
It is not necessary to file a Phabricator task or demonstrate consensus.
This facility is intended to allow these organisations to rapidly on-board staff members, who are assumed to be trusted by virtue of the hiring process. It also allows trusted organisations to grant access to volunteers who are well known and trusted by those organisations.
WMF employees may be added to the wmf group in LDAP when they are hired.
Wikimedia Deutschland employees may be added to the wmde group in LDAP when they are hired.
TechCom, or the CTO in consultation with TechCom, may direct a Gerrit administrator to add any person to a Gerrit group.
権限の失効
Revocation of Gerrit rights is permitted in the following circumstances:
- In an emergency, such as a compromised account, Gerrit administrators may revoke access immediately, at their discretion. 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.