提交和审查政策
WebKit 项目有两种除了贡献者之外的特殊身份。WebKit 提交者拥有对仓库的直接读写权限，使他们能够自行提交更改，或在作者要求提交者代劳时提交他人已审查的更改。WebKit 审查员被允许审查补丁，并可以批准或拒绝提交。有关审查和提交流程的详细信息，请参见贡献页面。
新的 WebKit 提交者和 WebKit 审查员将由现有 WebKit 审查员群体选出。为此，我们将创建一个邮件列表：<webkit-reviewers@lists.webkit.org>。
当前 WebKit 提交者和 WebKit 审查员的最新列表将在 webkit.org 上维护。
提交者和审查员的选择
WebKit 提交者或 WebKit 审查员的候选人应首先由一位审查员根据以下标准在审查员邮件列表中提名。如果所需审查员（见下文）附议该提名，则除非有人反对，否则该提名将在5个工作日内生效。如果提出异议，审查员应讨论此事并努力达成共识；如果未能达成共识，则此事将由审查员的多数投票决定。
一旦某人成功被提名为 WebKit 提交者，Apple 将负责发送提交者协议，并在签署并收到协议后授予读写权限。
一旦某人成功被提名为 WebKit 审查员，提名审查员或其他负责方应通知候选人，并征求潜在新审查员的接受意向。如果候选人接受，contributors.json 将被更新。
提交者标准
WebKit 提交者应是我们可以信任的人，他们会遵循并理解项目关于提交及其他事项的政策。
通常，潜在的提交者会在提交了大约 10-20 个好的补丁、表现出良好的判断力并理解项目政策、以及展示了良好的协作能力后被提名。要被提名和附议，他们需要与多位项目审查员互动。如果有人提交了许多补丁但未能表现出良好的判断力或有效的协作，该贡献者可能不会立即被提名。如果有人提交的补丁数量少于此，但有在其他基于 WebKit 或基于 khtml 的引擎中工作的经验，并有与 WebKit 项目良好协作的记录，他们可能会更快地被提名。
对测试、错误管理、网站内容、文档、项目基础设施及其他非代码领域做出重大贡献的人也可能被提名，即使没有达到通常的补丁数量门槛。
所有提交者提名都需要三位审查员的支持。一位审查员提名，另两位附议。
审查员标准
WebKit 审查员应是一个表现出特别良好判断力、理解项目政策、协作能力和理解代码能力的人。审查员应确保他们审查的补丁遵循项目政策，并尽力检查补丁中的错误或其他问题。他们也应在是否审查补丁或将其转交给其他审查员方面表现出良好的判断力。
潜在的审查员在提交了至少 80 个好的补丁后可能会被提名。他们还应与其他审查员保持联系，并了解各个领域的专家是谁。
提交了许多补丁但未表现出良好协作能力、代码理解或项目政策理解能力的人可能永远不会被提名。在成为审查员之前进行非官方审查是受到鼓励的。这是展示您技能的绝佳方式。请注意，在此类非官方审查中，您不应在补丁上标记 r+ 或 r-。
所有审查员提名都需要四位审查员的支持。一位审查员提名，三位审查员附议。
非活跃提交者或审查员状态
一年多未在项目中活跃的 WebKit 提交者或审查员被视为非活跃。为此目的，活跃定义为在过去一年内至少提交一个补丁。在过去一年内审查过补丁的审查员也将被视为活跃。
非活跃提交者可以通过提交（通过提交队列）一个非平凡补丁并在 webkit-committers 上请求恢复活跃状态来重新获得活跃提交者状态。
非活跃审查员需要通过提交至少 3 个非平凡补丁来表明他们正在努力熟悉自上次活跃以来项目中发生的变化。一旦他们提交了这些补丁，他们需要发送一封电子邮件至 webkit-reviewers 请求重新激活。此请求需要 2 位活跃审查员的支持才能获得批准。
请注意，无论提交者或审查员的活跃状态如何，任何在过去一年内未使用的账户都将出于安全目的被停用。例如，一位在过去一年内审查过补丁但未提交的审查员，其账户可能会被停用。要重新激活已停用的账户，活跃提交者或活跃审查员可以发送电子邮件至 webkit-committers 请求，除非有人反对，否则将在5个工作日内授予访问权限。
提交者或审查员状态的暂停和撤销
WebKit 提交者或 WebKit 审查员状态可以通过审查员三分之二的投票撤销，但不包括正在考虑撤销的个人。
任何积极破坏仓库或故意滥用其审查权限的人，其权限可能会应任何两位审查员的请求被暂时暂停。在此情况下，请求的审查员应通知 webkit-reviewers 列表，并描述违规行为。此时，审查员或提交者状态将被暂时暂停一周，等待永久撤销投票的结果。