开源项目中的变更管理

为什么还要费心为你的开源项目制定变更提案流程？为什么不让人继续做他们正在做的事情，并在功能准备就绪时合并它们呢？当然，如果你是项目中唯一的人，你可以这样做。或者，也许只有你和几个朋友。

但是，如果项目很大，你可能需要协调一些变更的落实方式。或者，至少让人们知道变更即将到来，以便他们可以调整，如果它影响到他们工作的部分。一个可见的变更流程对社区也很有帮助。它允许他们提供反馈，从而改进你的想法。退一步说，它让人们知道即将发生什么，以便他们可以感到兴奋，并可能为你争取到在 Opensource.com 或类似网站上的少量报道。基本上，它是“这是我将要做的事情”而不是“这是我所做的事情”，它可以让你在发布前匆忙进行 QA 时省去一些麻烦。

那么，假设我已经说服你，拥有一个变更流程是一个好主意。你如何构建一个流程呢？

[观看我关于这个主题的演讲]

适当调整你的变更流程

在我们开始讨论变更流程是什么样子之前，我想非常清楚地表明，这不是一种一刀切的情况。你的项目越小——主要是在贡献者的数量方面——你可能需要的流程就越少。正如 Richard Hackman 所说，团队中的沟通渠道数量随着团队人数的增加呈指数级增长。在社区驱动的项目中，这变得更加复杂，因为人们来来往往，甚至你的长期贡献者也可能不是每天都签到。因此，变更流程将这些沟通渠道整合到一个单一的区域，人们可以在这里快速查看他们是否关心，然后回到他们正在做的任何事情。

在一端，是我维护的命令行 Twitter 客户端。那里的变更流程是，“我选择一些我想做的事情，可能会为此创建一个 Git 分支，但我可能会忘记，合并它，并在我没有可以/想做的事情时标记一个发布版本。” 另一端是 Fedora。Fedora 实际上不是一个单一的项目；它是一个相关项目的程序，这些项目大多朝着相同的方向发展。每周有 200 多人在技术意义上接触 Fedora：spec 文件维护、构建提交等。这甚至不包括无数在上游工作的人。而这些上游都有自己的发布计划和自己的流程，用于功能如何落实以及何时落实。没有人可以独自跟上所有事情，因此变更流程将重要的变更公之于众。

决定谁需要审查变更

当你为你的社区制定变更流程时，你需要考虑的第一件事之一是：“谁需要审查变更？” 这不一定是要批准变更；我们稍后会讨论这个问题。但是，是否有人应该在流程的早期阶段查看它们？也许你的发布工程或基础设施团队需要审查它们，以确保它们不需要对构建基础设施进行更改。也许你有一个法律审查流程，以确保许可证井然有序。或者，也许你只是有一个变更管理员，他会查看以确保包含所有必需的信息。或者你可以选择不进行任何这些操作，并让变更提案直接提交给社区。

但这引出了下一步。你想要完整的社区反馈，还是只希望一个选定的群体提供反馈？我的偏好，以及我们在 Fedora 中所做的事情，是在变更获得批准之前将其发布到社区。但是你的社区结构可能适合某种模式，在这种模式中，一些批准机构在变更发送给社区作为公告之前对其进行签字。

确定谁批准变更

即使你没有任何形式的组织结构，也会有人最终批准变更。这应该反映你社区的规范和价值观。最简单的批准形式是提出变更的人实施它。轻而易举！在松散组织的社区中，这可能行得通。完全民主的社区可能会将其提交给社区范围的投票。如果一定数量或比例的成员投票赞成，则变更获得批准。其他社区可能会将该权力授予个人或群体。他们可以负责整个项目或某些子部分。

在 Fedora 中，变更批准是 Fedora 工程指导委员会 (FESCo) 的职责。这是一个由社区成员选举产生的九人机构。这使社区能够罢免那些没有为项目最佳利益行事的成员，同时也能够在没有大量开销的情况下做出相对快速的决策。

在本文的大部分内容中，我只是在介绍信息，但我现在要花一点时间来表达我的观点。对于任何拥有重要贡献者基础的项目，由一个小机构做出批准决定的模型是正确的方法。纯粹的民主可能会非常混乱。可能不熟悉变更的技术后果的人将能够投下具有约束力的票。并且该过程容易受到“围攻”的影响，即有人带来一大群原本不感兴趣的人来支持他们的立场。想想如果有人提议更改默认文本编辑器，情况会怎样。决策过程会是理性的吗？

计划如何强制执行变更

拥有一个明确的批准机构的另一个优势是它可以调解变更之间的冲突。如果两个拟议的变更发生冲突怎么办？或者，如果一个变更结果证明会产生负面影响怎么办？需要有人有权说“毕竟这个变更不会被采纳”或者确保冲突的变更达成一致。你的 QA 团队和流程将是其中的一部分，也许他们将是最终决定的人。

如果变更没有按预期工作或在截止日期前未完成，那么制定一个计划是相对简单的。如果你要求将应急计划作为变更流程的一部分，那么你就可以实施该计划。更难的部分是：如果有人进行了没有通过你的变更流程的变更会发生什么？这里有一个友好的项目经理不想让你知道的秘密：你无法强迫人们通过你的流程，尤其是在社区项目中。

因此，如果某些东西偷偷溜进来了，并且你在发布候选版本之前没有发现它，那么你有几个选择：你可以让它进来，或者你可以让人强制删除它。无论哪种情况，你都会有人非常不高兴。要么是进行变更的人，因为你踢出了他们的工作，要么是不得不处理它造成的破坏的人。（如果它在没有人注意到的情况下偷偷溜进来，那么它可能没什么大不了的。）

在任何一种情况下，答案都将是遵循流程的社会压力。流程有时很难遵循，但一个设计良好且维护良好的流程将带来比其成本更多的收益。在这种情况下，好处可能是更快地识别出破坏，或者让其他开发人员有机会利用提供的新功能。它可以帮助防止发布计划中的疏漏或 QA 团队的英雄式努力。

实施你的变更流程

因此，我们已经考虑了变更提案在你的项目中的生命周期。加入一些对你的发布节奏有意义的截止日期，你现在就可以制定政策了——但是你如何实施它呢？

首先，你需要确定变更提案所需的信息。至少，我建议以下内容。根据你的社区正在制作的内容及其运作方式的具体情况，你可能有更多要求。

• 名称和摘要
• 对项目的好处
• 范围
• 所有者
• 测试计划
• 依赖关系和影响
• 应急计划

你还需要一个或多个变更管理员。这些人与其说是守门人，不如说是牧羊人。他们可能没有能力批准或拒绝变更提案，但他们负责推动提案通过流程。他们检查提案的完整性，将其提交给适当的机构，发布适当的公告等。你可以让人管理他们自己的变更，但这可能是一项专门的任务，通常会受益于定期执行此操作的专职人员，而不是让社区成员不经常执行此操作。

你需要一些工具来管理这些变更。这可以是维基页面、看板、工单跟踪器、其他工具或这些工具的组合。但基本上，你希望能够跟踪它们的状态并提供一些关于变更状态的简单报告。这使得更容易知道哪些是完整的、哪些是有风险的以及哪些需要推迟到以后的版本。你可以使用最适合你的任何工具，但总的来说，你希望最大限度地减少复制粘贴并最大限度地提高可脚本化性。

记住要迭代

你的变更流程可能看起来很完美。然后人们将开始使用它。你会发现你没有考虑到的边缘情况。你会发现社区讨厌它的某些部分。曾经有效的决策会随着技术和社会的变迁而变得无效。在 Fedora 中，我们的功能流程显示出其本身是模糊且繁琐的，因此它被改进为我们今天使用的 变更 流程。即使变更流程比其前身好得多，我们仍然会不时地对其进行调整，以确保它最好地满足社区的需求。

在设计你的流程时，请确保它适合你的社区的规模和价值观。考虑谁在批准变更方面有发言权，谁有投票权。制定一个计划，说明你将如何处理不完整的变更和其他例外情况。决定谁将指导变更通过流程以及如何跟踪它们。一旦你设计了你的变更策略，请将其写下来，放在你的社区可以轻松找到的地方，以便他们可以遵循它。但最重要的是，请记住，流程是为了服务社区而存在的；社区不是为了服务流程而存在的。