提交者
作为所有开源项目中唯一正式的明确阶层，需要对提交者格外关注。提交者是系统中不可避免的对鉴别的让步，而其他角色则是尽可能的非鉴别。但是“鉴别”这里绝无轻视的含义。提交者发挥的功能是绝不可少的，我不相信一个项目会在没有这个角色的情况下取得成功。我们需要质量控制，是的，控制。总会有许多人觉得自己具备对某个程序修改的能力，但实际上只有少数人确实具备。项目不能依赖人们自己的判断，必须设置标准并为达到标准的人赋予提交权限[28]。 另一方面，要让可以直接提交变更的人与不能设置明显权利变化的人一起工作。这种变化必须是受管理的，这样才不会损害项目。
在Chapter 4, 社会和政治的基础架构的the section called “谁进行表决？”，我们已经讨论考虑过新提交者的机制。这里我们会讨论潜在的新志愿者必须被判断的标准，以及在一个大的社区中如何展示这个过程。
选择提交者
在Subversion项目，我们主要根据希波克拉底原理选择提交者：首先，不要伤害。我们的主要标准不是技术技巧或对代码的认识，仅仅是提交者展示出好的判断。判断仅意味着知道不要做什么。一个人可以只发布小的补丁，修正代码中的小问题；但只要这个补丁能够干净的应用，不会带来新的bug，能够最大程度的符合项目的日志信息和代码习惯，而且有足够多的补丁可以展示明显的模式，则现有的提交者通常会提议为该人赋予提交权限。如果至少三个人赞成，且没有人反对，则提议通过。诚然，也许我们没有证据证明这个人有能力解决代码基所有部分的复杂问题，但这并不重要：他所做的已经证明他至少能对自己的能力有正确的判断。技术技巧可以习得（和讲授），但无法获得最重要的判断。然而，在赋予一个人提交权限之前，这是你需要确保某人所具备的能力。
当一个新的提交者提议引起了讨论，通常不会是关于技术能力，而是关于该人在邮件列表或IRC中的行为方式。有时，某人展示了技术能力和按照项目正式方针工作的能力，以及在公共论坛中一致的好战或不合作性。这需要认真的关注；如果即使经过了回复的提示，这个人也一直未能改变，我们不会将其添加为提交者，无论其技巧怎样高。在一个志愿者团队中，社会技巧，或者说在“沙盒中玩耍的”能力，与原始的技术能力同样重要。因为任何东西都会进入版本控制，添加一个不该添加的提交者不会在代码层面带来太多的问题（评审可以迅速定位这些问题），但那样会导致最终强制项目收回该人的提交权限—这绝不是一项让人愉快的行为，有时会让人失望。
许多项目坚持潜在的提交者展示了特定级别的技术专业技能和持久性，通过提交一定数量的非琐碎补丁—也就是项目不仅仅希望知道他不会伤害项目，而且希望知道他会使项目在代码基上获益。这样很好，但是要小心，不要将提交权变为一个排他俱乐部的身份。每个人的脑子中都应该有一个问题：“怎样做才会为代码带来最好的结果？”而不是“认可这个人是否会降低提交权关联的社会状态的价值？”如果您有100个提交者，10个进行常规的较大的变更，而其他90个则仅仅是每年修正几个拼写和小的bug，依然比只有10个提交者更好。
收回提交权限
关于收回提交权限首先要做到：尝试不要一开始就进入这种情况。取决于谁的权限将会被收回，以及收回的原因，相关的讨论将会显著不同。即使没有不同，这也将会是有效率工作的一项费时的分心的工作。
然而，如果您必须如此，一定要确保讨论必须处于将会为该人赋予权限进行投票的人之间，无论他们拥有怎样的投票风味。一定不要包含本人。这似乎否定了针对保密性的禁令，但在这种情况下这是必要的。首先，没有人能够以别的方式自由言论。其次，如果行动失败，你不会希望让此人知道这被考虑过，因为这会带来一些问题（“谁站在我这边？ 谁反对我？”），会导致最坏类型的党派主义。在一些罕见的情形下，团队会希望某人知道收回提交权限的过程正在进行中，作为警告提示，但一定要确保这种公开是团队决策的结果。任何人不应当擅自行动，将别人认为是秘密的讨论信息和表决透漏出去。
一旦收回了某人的权限，结果必然要公开（见本章后面的the section called “避免神秘”），你需要尝试尽可能谨慎的公布于众。
部分提交权限
有些项目提供细粒度的提交权限。例如，有些贡献者的提交权限限于文档，而不能是代码。常见的部分提交权限包括文档、翻译、其他语言的绑定代码，打包的特定文件（例如RedHat RPM规范文件等等），以及其他即使发生错误也不会导致核心项目问题的地方。
因为提交权限不仅仅关于提交，而且事关选举资格（见Chapter 4, 社会和政治的基础架构的the section called “谁进行表决？”），自然回带来另一个问题：部分提交者能够为何投票？没有一个正确的答案；这取决于你的项目有何种部分提交领域。在Subversion中，我们尽可能让事情简单：一个部分提交者只可以参加提交者领域的部分投票，其他地方则不行。更重要的，我们有一个可以覆盖建议投票的机制（其实质在于，表决时提交者可以写"+0"或"+1 （非绑定）"，而不仅仅是"+1"）。......................
完全提交者可以为任何事情投票，就像他们可以任意提交一样，只有完全提交者可以为添加所有类型的提交者投票。在实践中，通常这种添加新部分提交者的能力通常会被代理：任意完全提交者可以“发起”一个新的部分提交者，而且某个领域的部分提交者通常会为同一领域选择新的提交者（这在保证翻译工作正常运行时特别有益）。
你的项目可能有些许不同的安排，这取决于你所作工作的特性，但相同的原理适用于所有的项目。每个提交者必须能为她提交权限相关的事物进行投票，不相关的则不能，而且程序上的问题默认由完全提交者表决，除非有原因（要由完全提交者决定）来扩大投票范围。
关于部分提交权限的强制性：最好不要让版本控制系统约束提交领域，即使技术上可行。原因请见Chapter 3, 技术基础设施的the section called “授权”。
休眠提交者
一些项目会在提交者在一定时间（例如一年）内未能提交任何东西时，自动删除其提交权限。我认为这样没有太大帮助，甚至有不良的后果，有以下两个原因。
首先，这会诱使人们提交可接受但不必要的变更，仅仅为了保住将要过期的提交权限。其次，这样没有意义。如果赋予提交权限的主要标准是判断力，为何仅仅因为他离开了项目就认为其判断力的下降？即使他完全的消失了几年，没有看任何代码或跟踪开发讨论，但当他重新出现时，他会知道他已经多久未从联系，并以此行动。你原来相信他的判断，为何不永远相信他？如果高校的文凭不会过期，那么提交权限也不应该。
有时，一个提交者会要求将其删除，或在提交者列表中明确的标记为休眠状态（关于该列表的更多信息见后面的the section called “避免神秘”）。在这种情况下，项目当然必须答应个人的意愿。
避免神秘
尽管围绕添加特定新提交者的讨论必须保持机密，其规则和步骤本身不应该保密。实际上，最好公开，这样人们可以意识到提交者并不是什么神秘的秘密法庭，也不是凡人免进，而是任何人可以参与，仅需要发布一些好的补丁，并指导如何在社区中交流。在Subversion项目中，我们将信息放在开发指南文档中，因为那些希望为项目贡献代码的人们对如何赋予提交权限最有兴趣。
除了发布步骤，也要发布提交者列表。该文件的传统位置是项目代码树顶级目录中叫做MAINTAINERS或COMMITTERS的文件。它首先必须列出所有的提交者，紧跟是多个部分提交域以及其中的提交者。要列出每个人的名字，如果该人愿意，也包括邮件地址，地址可以为防止垃圾邮件进行编码（见Chapter 3, 技术基础设施的the section called “归档中的地址隐藏”）。
因为完全提交者和部分提交者访问权限有着明显的区别，也做出了明确的定义，所以这个列表也应该列出这种区别。除此以外，该列表不应当试图表明项目中不可避免会出现的非正式的区别，例如谁更具影响力。它是公共记录，不是致谢文件。请使用字母顺序或其出现顺序列出提交者。
[28] 请注意，在非集中式的版本控制系统中，提交权限的含义有些区别，在非集中式系统中，任何人可以建立与项目关联的版本库，并为自己设置到该库的访问权限。然而，提交权限的概念依然适用：“提交权限”是“改变软件下一次发布中输送代码的权利”的缩写。在集中式版本控制系统中，这意味着直接的提交权限；在非集中式系统中，这表示了将某人的变更默认拖入主发布。其实是相同的含义；其实现的机制并不重要。