Jump to content

Gerrit/权限方针

简写： Gerrit/+2
From mediawiki.org
This page is a translated version of the page Gerrit/Privilege policy and the translation is 43% complete.
Languages:

权利和义务

在大多数维基媒体Gerrit仓库设置中，如果一名用户给出了“+2”的代码审查结果，Jenkins便会在运行测试后自动合并这一更改。 所以给出代码审查+2的权限只赋予特定Gerrit用户组。 通常，每个代码仓库都有以仓库命名的Gerrit用户组，且在该仓库具有权限。 同时，有些Gerrit组在多个代码仓库都有权限。 尤其是mediawiki组在MediaWiki内核和所有扩展与皮肤都有权限，外加其他一些与MediaWiki相关的仓库。

Gerrt组可以继承LDAP组的成员。 绝大多数WMF雇员都属于LDAP的wmf组，从而自动拥有mediawiki组的成员资格。

Gerrit管理员可以向Gerrit组中添加或移除成员。

将更改合并到MediaWiki核心或Wikimedia部署的扩展是一件大事。 一旦更改被合并到Gerrit 中，它将“自动”部署到Beta叢集 ，这是一个虚拟化的暂存环境。 它也将在下一个MediaWiki核心部署窗口中“自动”拾取（请参见部署），除非在剪切发布分支之前将其还原。

您的合并操作可能导致维基百科或其他站点崩溃。 也可能引入安全漏洞，而让攻击者删除、破坏数据，或访问私人信息。 更常见的情况是，如果代码没有测试、测试实现得很差或交互很差，则可能会导致technical debt 增加。 在使用+2之前，您应该仔细阅读本文档和所有相关政策。

+2是信任的强烈表达，通过良好的判断和谨慎的行动来保持信任。

在代码审查、设计讨论和bug评论中，那些拥有+2能力的人有特殊的责任从他人的角度来看问题。

合并而不审查

未经审查就合并代码不利于代码质量，也不利于士气。 +2权限的意义在于“分离开发和代码审查”。 合并Gerrit中的更改的目的是告诉世界：“是的，我已经确保此更改遵循MediaWiki惯例、良好的工程实践，并且是合理的。” （参见Jeff Atwood的“代码评论：就这么做”。） 内联注释可以用来指示在合并代码之前应该解决的代码问题。

未经审阅者批准而合并您自己的代码可能会被吊销特权。

这不一定等同于给自己拥有的Gerrit更改+2。 事例：

  • 如果一个更改从审核者那里收到+2，但Jenkins构建失败，则所有者可能需要给它+2才能重新启动构建作业。
  • 恢复通常可以自我合并，只要它正在恢复的提交是最近的。 您正在恢复到当时可能已审核的版本。
  • 在部署分支和Puppet存储库中，更改由执行部署的人员（通常也是作者）合并。 在这些情况下，代码评审通常通过对更改加1表示。
  • Gerrit中的提交可能有两个作者：所有者和上传修改的审阅者。 通常，所有者和审阅者各自审阅对方的作品。 只要所有更改都经过审查和批准，提交就可以合并。

很少有更改是微不足道的，足以进行自我合并。 在某些情况下，比如琐碎的文档更改或只有一个维护人员的项目，可以容忍自合并。

对于未部署到Wikimedia集群的扩展（和其他项目），代码审查策略由扩展的维护者或作者决定。 一些非维基媒体扩展遵循维基媒体禁止自合并的政策，但没有这方面的要求。 如果您是唯一一个编写扩展的人，并且没有人审查您的更改，或者如果扩展被放弃，则可以自行合并您的更改。

团队内部审查和共享所有权

如果你是团队的一员，不仅允许团队成员进行审查，而且强烈鼓励。 让同行不断地审查您的代码是保持开发势头的好方法，并确保您的审查人员熟悉您正在做的事情。

当你进行团队内部审查时，要特别注意盲点，认知偏见，以及需要接受你所在团队之外的重大变化。 大多数开源项目，包括MediaWiki，都充满了创建新奇的抽象层、蒙皮系统、测试框架等被放弃的努力。 考虑你的变化对整个生态系统的影响，并通过评论请求、wikitech-l、IRC和其他场所进行对话。 Shared ownership of code (to a greater or lesser degree) helps to ensure that what you're doing has lasting long term value.

Must read for code reviewers

申请Gerrit权限

如需申请加入mediawiki组，请在Phabricator的MediaWiki-Gerrit-Group-Requests项目下创建一个task。 然后发一封电子邮件到wikitech-l邮件列表。

To request membership in another group, create a new task under the Gerrit-Privilege-Requests project in Phabricator.

无论您是哪种情况，都需要在task中注明：

  • Gerrit用户名
  • 您需要哪个（些）仓库的权限
  • 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.

Expedited process for trusted organisations

Gerrit administrators may immediately act on requests from the following trusted organisations for the granting and revocation of membership in their managed groups, specifically:

Organisation Managed groups
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

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 socialise 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.

Requesting revocation

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:

Scenario Action
  • A developer uploads and self-merges plainly malicious code.
  • Contact a Gerrit administrator for emergency revocation.
  • A developer shows a pattern of merging flawed changes, without proper review.
  • A developer repeatedly merges their own code, in violation of community norms.
  • If the developer is an employee of WMF or a trusted organisation, report the problem to their manager.
  • If the manager's response was unsatisfactory, or if the developer is not an employee, report the problem to TechCom.
  • If TechCom's response is unsatisfactory, you may report the problem to the CTO.
  • A developer uses their +2 access to bully or intimidate developers seeking review.
  • Other behaviour issues or Code of Conduct violations.
  • If the developer is an employee of WMF or a trusted organisation, and you feel comfortable doing so, report the problem to their manager.
  • Otherwise, report the problem either to TechCom or to the Code of Conduct committee.
  • If the committee's response is unsatisfactory, you may report the problem to the CTO.

Amendments to this policy

Amendments to this policy must be approved by the CTO, in consultation with TechCom.

Definitions

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.
Retrieved from "https://www.mediawiki.org/w/index.php?title=Gerrit/Privilege_policy/zh&oldid=6515710"