Gerrit/权限方针
This page documents an official Wikimedia development policy. There is no current mechanism to make changes, as the TechCom RFC process is defunct. |
| Development policies |
|---|
| See also |
| 开发指引 |
权利和义务
大多数维基媒体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、和其他场所进行对话。 程式碼的共同所有權（程度或深或淺）有助於確保您的付出具有持久的長期價值。
程式碼審查者必讀
- 程式碼審查指引
- Security for developers
- Manual:代码编写约定 – 及其子頁面
- Manual:单元测试 – 及其相關頁面
- 本地化
- Database optimization – 在進行架構變更時請謹記此點（變更應遵循此流程實施）
- Manual:如何调试
申请Gerrit权限
如需申请加入mediawiki组，请在Phabricator的MediaWiki-Gerrit-Group-Requests项目下创建一个task。
然后发一封电子邮件到wikitech-l邮件列表。
如需申请加入另一個组，请在Phabricator的Gerrit-Privilege-Requests项目下创建一个task。
无论您是哪种情况，都需要在task中注明：
- Gerrit用户名
- 您需要哪个（些）仓库的权限
- 說服的理由，包含你已撰寫與已審查的修補程式的連結
開發者在評論特權的申請時，應考量申請者是否曾提交高品質的修補程式、妥善行使+1的權限、以及展現出相應的能力。 負面的評論應以委婉的方式撰寫，切勿過於尖銳。
若Phabricator任務獲得受信任的開發者的共識，任何Gerrit管理員皆可處理該請求。 任務必須保持公開至少一週，以便讓有興趣的開發者發表評論。 若申請是在旅遊或假期的期間公開的，應預留額外時間。
若在 Phabricator 中對某項請求未能達成共識，可將其提交至 TechCom 進行裁決。
先前，某些擴充功能維護者被授予相關的Gerrit專案的擁有權限，讓他們無需提交申請即可在Phabricator之中新增群組成員。 此模式不應用於新的擴充功能。 Gerrit 管理員不應將儲存庫的擁有權授予普通開發人員。 在擴充功能首次部署至維基媒體叢集之前，應審核其權限，並將舊有擁有者權限降級為+2存取權限。
受信任組織的加速流程
Gerrit管理員可立即處理來自下列受信任組織的請求，以授予或撤銷受其管理的群組的成員資格，具體包括：
| 組織 | 受其管理的群組 |
|---|---|
| Wikimedia Deutschland | wmde, wmde-mediawiki
|
| ShoutWiki | ShoutWiki, Brickimedia
|
| Hallo Welt! | bluespice
|
| WikiTeq | WikiTeq
|
無需提交Phabricator任務或展示出共識。
此機制旨在讓這些組織能快速接納那些憑藉招聘流程而被視為值得信賴的員工。 它也可讓受信任的組織向那些為該組織所熟知且值得信賴的志工授予存取的權限。
維基媒體基金會的員工在入職時可被添加至轻型目录访问协议(LDAP )中的wmf 群組。
維基媒體德國分會的員工在入職時，可被加入轻型目录访问协议(LDAP )中的 wmde 群組。
技術委員會（TechCom），或由產品與技術總監（CPTO）經與技術委員會協商後，可指示Gerrit管理員將任何人員加入Gerrit群組。
撤銷
在以下情況下，允許撤銷Gerrit的權限：
- 在緊急情況下（例如帳戶遭入侵），Gerrit管理員可酌情立即撤銷存取權限。 若認定緊急狀況已解除，管理員可酌情撤銷緊急撤銷措施。 技術委員會（TechCom），或由產品與技術總監（CPTO）經與技術委員會協商後，得審查緊急撤銷決定，並指示撤銷該決定。
- 根據《員工手冊》所述，WMF員工的權限撤銷可由該員工的主管在徵詢WMF人才與文化部門意見後決定。
- 技術委員會（TechCom）得指示撤銷任何人的特權，或由產品與技術總監經與技術委員會（TechCom）協商後作出此決定。
撤銷的理由可能包括：
- 合併不良程式碼
- 未經審查即合併自己的程式碼
- 未能在開發社群內有效溝通具重大影響的變更
- 未遵循上述指引
- 不當行為，尤其是違反行為準則
- 終止僱傭關係或合約
根據 WMF 的政策，當員工離職時，所有權限均將被撤銷，即使該等權限是基於志工工作而在僱用關係開始前所授予的。 一貫執行此政策有助於保護離職員工的隱私：此舉絕非暗示其有任何過失。 若離職同仁希望以志工身分繼續貢獻心力，可依照常規程序重新申請存取權限。
申請撤銷
如需緊急撤銷，應直接聯繫 Gerrit 管理員提出請求，例如使用 IRC。 基於職能或行為原因而撤銷資格，通常應遵循既定的升級處理流程，在非公開場合進行處理。 更多詳情請參閱下表：
| 情境 | 動作 |
|---|---|
|
|
|
|
|
|
本政策之修訂
本政策的任何修訂，均須經 CPTO 徵詢 TechCom 意見後批准。
定義
- CPTO
- 維基媒體基金會的產品與技術總監。
- TechCom
- 維基媒體技術委員會。 若要由技術委員會（TechCom）作出決定或下達指示，則須召開委員會會議（不論是以遠距視訊會議或實體會議形式舉行），且須有至少半數技術委員會成員出席以構成法定人數，並以簡單多數決或全體一致同意通過決議。