变更管理 开源_管理开源项目中的变更

变更管理 开源

为什么要烦恼提议对开源项目进行更改的过程？ 为什么不让人们做他们正在做的事情并在准备就绪时合并功能呢？ 好吧，如果您是该项目的唯一人员，那么您当然可以这样做。 或者，也许只有您和几个朋友。

但是，如果项目规模很大，则可能需要协调某些更改的实施方式。 或者，至少要让人们知道即将到来的更改，以便他们可以调整它是否影响他们工作的部分。 可见的变更过程也对社区有所帮助。 它使他们能够提供反馈，以改善您的想法。 而且，如果没有别的，它可以使人们知道即将发生的事情，从而使他们感到兴奋，并可能使您对Opensource.com或类似内容有所了解。 基本上，这是“这就是我要做的事情”，而不是“这是我所做的事情”，当您在发布之前进行质量检查时，它可能会为您省去一些麻烦。

假设我已经说服了您，变更流程是一个好主意。 你如何建立一个？

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

正确确定您的变更流程

在我们开始讨论变更过程之前，我想清楚地表明这不是千篇一律的情况。 您的项目越小（主要是贡献者的数量），您可能需要的过程就越少。 正如Richard Hackman所说 ，团队中的沟通渠道数量与团队中的人数成倍增加。 在社区驱动的项目中，随着人们来来往往，这变得更加复杂，甚至您的长期捐助者也可能每天都无法检查。 因此，变更过程将这些沟通渠道整合到一个区域中，人们可以在其中快速检查自己是否在乎，然后回到所做的一切。

一方面，我维护着命令行Twitter客户端。 更改过程是，“我选择了我想做的事情，可能为此创建了一个Git分支，但是当我没有能力/想要做的事情时，我可能会忘记，合并它并标记一个发行版。 ”。 另一端是Fedora。 Fedora并不是一个真正的项目。 这是一个相关项目的计划，大部分都朝着同一方向发展。 每周有200多人从技术角度接触Fedora：规范文件维护，构建提交等。这甚至不包括在上游工作的人数之多。 这些上游都有自己的发布时间表和功能降落和时间的过程。 没有人可以独自掌握所有内容，因此变更过程会带来重要的变化。

决定谁需要审查变更

在为社区制定变更流程时，您需要考虑的第一件事是：“谁需要审查变更？” 这并不一定要批准更改； 我们很快就会谈到。 但是是否有人应该在此过程中尽早观察？ 也许您的发布工程师或基础架构团队需要对其进行审查，以确保他们不需要更改即可构建基础架构。 也许您有一个合法的审查程序，以确保许可证是正确的。 或者，也许您只有一名变更争吵者，他希望确保已包括所有必需的信息。 或者，您可以选择不执行任何操作，而将更改建议直接提交给社区。

但这引出了下一步。 您是要获得社区的完整反馈，还是只希望有一部分人提供反馈？ 我的偏好以及我们在Fedora中所做的工作是在更改获得批准之前将更改发布到社区。 但是，您的社区的结构可能适合这样的模型：某些批准机构在将更改作为公告发送给社区之前会对其进行签名。

确定谁批准变更

即使您缺乏任何类型的组织结构，最终还是会有人批准变更。 这应该反映您社区的规范和价值观。 批准的最简单形式是提出更改的人实施它。 十分简单！ 在松散组织的社区中，这可能会起作用。 完全民主的社区可能会将其投票给整个社区。 如果一定数量或比例的成员投票赞成，则更改被批准。 其他社区可以将该权力赋予个人或团体。 他们可能负责整个项目或某些小节。

在Fedora中，变更批准是Fedora工程指导委员会（FESCo）的职责。 这是一个由社区成员选举产生的9人机构。 这使社区能够罢免那些不以项目的最大利益为出发点的成员，但也可以做出相对快速的决策而无需大笔开销。

在本文的大部分内容中，我只是介绍信息，但是我将花点时间提出自己的看法。 对于任何具有大量捐助者基础的项目，由小规模机构做出批准决策的模型都是正确的方法。 纯粹的民主可能会很混乱。 可能不熟悉更改的技术影响的人将可以进行具有约束力的投票。 而且该过程需要“过渡”，即有人会带来一大批原本不感兴趣的人来支持他们的立场。 想一想如果有人建议更改默认文本编辑器可能会是什么样子。 决策过程是否合理？

计划如何实施更改

具有定义的批准机构的另一个优点是，它可以调解变更之间的冲突。 如果两个建议的更改冲突怎么办？ 还是如果发现变更会产生负面影响？ 有人需要有权说“这根本不会发生”，或确保将冲突的更改达成协议。 您的质量检查团队和流程将是其中的一部分，也许他们将成为最终决定者。

如果更改无法按预期进行或在截止日期之前未完成，则提出计划相对容易。 如果您需要应急计划作为变更过程的一部分，则可以实施该计划。 更难的部分是：如果有人进行了不经过您的变更过程的变更，会发生什么？ 这是您友好的项目经理不希望您知道的一个秘密：您不能强迫人们完成您的流程，尤其是在社区项目中。

因此，如果某件事情悄悄溜走了，直到找到候选发布版才发现它，您有两种选择：您可以允许它进入，也可以让某人强行删除它。 无论哪种情况，您都会遇到一个非常不高兴的人。 进行更改的人是因为您踢了他们的工作，或者是不得不处理更改造成的损坏的人。 （如果它在没有任何人注意的情况下潜入，那么这可能没什么大不了的。）

不管是哪种情况，答案都将是跟随该过程的社会压力。 有时很难遵循流程，但是精心设计和维护良好的流程所带来的收益将超过成本。 在这种情况下，其好处可能是可以更快地识别出破损或为其他开发人员提供利用所提供的新功能的机会。 而且，它可以帮助防止发布计划中的延误或QA团队的努力。

实施您的变更流程

因此，我们已经考虑了您的项目中变更提案的寿命。 投入一些对发布节奏有意义的期限，现在您可以提出该策略，但是您如何实施它？

首先，您需要确定变更建议所需的信息。 至少，我建议以下内容。 您可能有更多要求，具体取决于您社区的具体组成及其运作方式。

• 名称和摘要
• 受益于项目
• 范围
• 所有者
• 测试计划
• 依存关系和影响
• 应急计划

您还将需要一个或多个变更争吵者。 与牧羊人不同，这些人不是守门人。 他们可能没有能力批准或拒绝变更建议，但是他们有责任在整个过程中移动建议。 他们检查提案的完整性，将其提交给适当的机构，做出适当的公告等。您可以让人们纠缠自己的更改，但这可能是一项专门的任务，通常会受益于定期进行此工作的专职人员减少社区成员这样做的频率。

您将需要一些工具来管理这些更改。 这可能是Wiki页面，看板，票务跟踪器，其他内容或这些的组合。 但基本上，您希望能够跟踪它们的状态并提供一些有关更改状态的简单报告。 这样可以更轻松地了解已完成的内容，面临的风险以及需要推迟到以后的版本中的内容。 您可以使用最适合自己的方法，但总的来说，您将需要最大程度地减少复制和粘贴并最大化脚本性。

记得要迭代

您的更改过程可能看起来很完美。 然后人们将开始使用它。 您会发现自己没有考虑的情况。 您会发现社区讨厌其中的一部分。 随着技术和社会的变化，曾经有效的决策将随着时间的推移而失效。 在Fedora中，我们的“功能”过程显示出模棱两可且繁重，因此已被完善为我们今天使用的“ 更改”过程。 尽管“变更”流程比其前身要好得多，但我们仍在此进行调整，以确保它能最好地满足社区的需求。

在设计流程时，请确保其适合您社区的规模和价值。 考虑谁可以发表意见，谁可以投票赞成变更。 提出有关如何处理不完整的更改和其他异常的计划。 确定谁将在整个过程中指导更改以及如何对其进行跟踪。 设计变更策略后，请将其写下来，以便社区容易找到，以便他们可以遵循。 但最重要的是，请记住，该过程已在为社区服务。 社区不是在为这个过程服务。

翻译自: https://opensource.com/article/19/3/managing-changes-open-source-projects

变更管理 开源