原文：Managing changes in open source projects   
作者：Ben Cotton，编译：御坂弟弟

本文是一篇关于如何创建一个可见的变更流程来支持开源项目社区的文章。

为什么要费心为开源项目制定一个提出变更的流程呢？为什么不让人直接提交然后合并功能？如果项目中只有你或者只有你和几个朋友，你当然可以这么做。

但如果项目很大，那么为变更进行一些协调工作是更好的选择。最起码要让人们知道一个变更即将到来，以便在其可能影响到他们工作的部分时进行调整。一个可见的变更过程对社区同样有益，这将允许关注该项目的人及时给出反馈，而这或许可以改进该变更最初的想法。人们总是会对预知即将发生的事情感到兴奋，因此一个可见的变更流程也许会让项目在 Opensource.com 或类似的地方得到一些报道，这也会帮助省去发布前的 QA 工作中的一些麻烦。

那么，如何建立一个可见透明的变更流程？

确定变更流程的规模

项目越小（通常有贡献者数量反映）则流程就应越短，这是一个放之四海而皆准的原则。正如 Richard Hackman 所说，一个团队的沟通渠道数量会随着团队人数的增加而成倍增加。在社区驱动的项目中，这会变得更加复杂，人员来往频繁，甚至项目的长期贡献者也可能不会每天都来检查。因此，变更流程应该将这些沟通渠道整合到一个单一区域，方便人们快速检查是否与自己相关，然后回到他们所做的任何事情上。

这里例举两个例子。对于命令行 Twitter 客户端，其变更流程是，"当我选择一些我想做的事情时，可能会为它做一个 Git 分支，但我可能会忘记；合并分支；当我没有可以/想做的事情时，就标记一个版本"。另一个例子是 Fedora。Fedora 并不是一个真正的单一项目，它是一个由相关项目组成的程序，这些项目大多朝着同一个方向发展。每周有超过 200 人在技术意义上接触 Fedora：规范文件维护、构建提交等等。这还不包括数不清的在上游工作的人。而这些上游都有自己的发布时间表和自己的流程来决定功能如何落地和何时落地。没有人能够自己跟上所有的事情，所以变更流程会曝光重要的变更。

决定由谁来审核变更

当社区制定一个变更流程时，需要考虑的第一件事就是："由谁来审查变更"。 这不一定是批准变更，下文会很快谈到这一点。但是否应该有一些人在流程的早期就关注到变更？也许社区的发布工程或基础设施团队需要审查它们，以确保它们不需要更改来构建基础设施。也许社区有一个法律审查过程，以确保许可证是合法的。或者社区只是需要有一个变更管理员，负责确保所有所需的信息都包含在内。或者选择不做这些，让变更提案直接提交给社区。

但这就带来了下一个问题：你是想要完整的社区反馈，还是只让一个选定的群体提供反馈？Fedora 的做法是，在批准之前向社区发布修改。但有的社区结构可能更适合这样的模式，即在变更被作为公告发送到社区之前，先经过一些审批机构签署。

确定由谁来批准变更

即使项目没有任何形式的组织结构，也需要有人最终批准更改。这应该反映出项目所在社区的规范和价值观。最简单的批准形式是由提出改变的人去实施它：在松散的组织结构中，这就是所谓的 "批准"。这在组织松散的社区中可能是可行的。而完全民主的社区可能会通过全社区投票来决定。如果有一定数量或比例的成员投赞成票，这个变更就被批准了。其他社区可能会把这个权力交给某个个人或团体，他们可能负责整个项目或某些子部分。

在 Fedora 中，变更审批是 Fedora 工程指导委员会（FESCo）的职责，这是一个由社区成员选出的九人机构。该机构让社区有能力去掉那些不符合项目最佳利益的成员，也能在没有大量开销的情况下相对快速地做出决定。

对于任何一个有重要贡献者基础的项目来说，由一个小机构进行审批决策的模式才是正确的做法。纯粹的民主会导致混乱。那些可能对某项修改的技术后果并不熟悉的人，也能够投出具有约束力的一票。而这一过程还会会受到 "拉帮结派 "的影响，即有人带着一大群其他不感兴趣的人支持他们的立场。比如，如果有人提议改变默认的文本编辑器，会是什么样子？决策过程是否合理？

计划如何实施变更

有一个明确的审批机构的另一个好处是它可以调解变更之间的冲突。如果两个提议的变更发生冲突怎么办？或者如果一个变更被证明有负面影响？需要有人有权力说 "拒绝"，或者确保冲突的变更被纳入协议。项目的 QA 团队和流程也是其中的一部分，也许他们才是做出最终决定的人。

如果一个变更没有按预期进行，或者在截止日期前没有完成，则需要对此拿出一个确切的计划。如果项目已经有一个应急计划作为变更流程的一部分，那么就实施这个计划。更难的是：如果有人做了一个没有经过你的变更流程的变更，会发生什么？这里有一个关键：你不能强迫人们通过你的流程，特别是在社区项目中。

所以，如果有什么东西偷偷溜进来，而你直到第一个 RC 版本时才发现，你有几个选择：你可以让它进来，或者你可以找人强行删除它。无论哪种情况，都会有一个人非常不高兴：要么是做出改变的人，因为你把他们的工作踢出去，要么是不得不处理它造成的破坏的人。

无论是哪种情况，答案都会是社会压力。因此，需要按照流程来。流程有时是很痛苦的，但一个设计良好、维护良好的流程所带来的好处会比它的成本更多。在良好的流程中，人们可以更早地发现破绽，或者给其他开发人员提供利用新功能的机会。而且良好的流程可以帮助防止发布时间表的延迟，减轻 QA 团队的负担。

实施变更流程

那么，该如何实施变更流程呢？

首先，需要确定变更提案所需的信息。一个变更应该至少包括以下信息：

• 名称和摘要
• 对项目的益处
• 范围
• 作者
• 测试计划
• 依赖性和影响
• 应急计划

此外，项目还需要一个或几个 ”牧羊人“，他们可能没有能力批准或拒绝变更提案，但他们负责在整个过程中推动提案。他们检查提案的完整性，将其提交给适当的机构，并做出适当的宣布，等等。也可以让人们自己来处理自己的变更，但一般来说，由专人定期做这件事会更好。

你还需要一个或几个找零的人。这些人不是看门人，而是牧羊人。他们可能没有能力批准或拒绝变更提案，但他们负责在整个过程中推动提案。他们检查提案的完整性，将其提交给适当的机构，并做出适当的宣布，等等。你可以让人们自己来处理自己的变更，但这可能是一项专门的任务，一般来说，由专人定期做这件事会有好处，而不是让社区成员少做。

项目还需要一些工具来管理这些变化。这可能是一个 wiki 页面，一个 kanban 板，一个 ticket 跟踪器或其他的东西，或者这些的组合。主要目的在于通过这些工具跟踪变更提案的状态，并提供一些简单的变化状态报告。这样可以更容易地知道什么是完整的，什么是有风险的，什么需要推迟到以后的版本。在这方面可以使用任何方法，但一般来说，应该尽量减少复制和粘贴，并最大限度地提高脚本性。

牢记迭代

一个变更流程可能看起来很完美。然后当人们会开始使用它时，可能会发现一些没有考虑到的边缘案例。比如，随着技术和社会的变化，曾经有效的决定会随着时间的推移变得无效。因为 Fedora 中的 Features 流程表现出了它的模糊和繁琐，所以它被改进为今天使用的 Changes 流程。尽管这个变更流程比它的前身要好得多，但仍然会经常进行调整，以确保它能最好地满足社区的需求。

当设计一个 变更流程时，要确保它适合项目的社区的规模和价值。考虑在批准变更时，谁有发言权，谁有投票权。为如何处理不完整的变更和其他例外情况制定一个计划。决定由谁在整个过程中指导变更，以及如何跟踪这些变更。一旦变更政策被确定，就把它写在一个容易让社区成员找到的地方，这样他们就可以遵循它。但最重要的是，请记住，流程是为社区服务的；社区不是为流程服务的。