保持开源项目活力，当人们离开时

假设有一天你醒来，决定 наконец 使用你在社交媒体上反复观看的食谱视频。你准备好食材，整理好必要的用具，然后开始按照食谱步骤操作。你切这个，切那个，然后开始加热烤箱，同时在平底锅里放入黄油和洋葱。这时，你的手机提醒你：你和老板有一个晚餐约会，而且你已经迟到了！你关掉所有东西，立即离开，在接近结束时停止了烹饪过程。

几分钟后，你的室友回到家准备吃晚饭，却只发现厨房里正在进行的工作。他们有以下选择

1. 清理混乱，然后从头开始烹饪一些东西。
2. 订购晚餐，不要费心烹饪和/或收拾你留下的烂摊子。
3. 在你留下的烂摊子“周围”开始烹饪，这可能会花费更多时间，因为大多数用具都很脏，而且厨房里没有多少空间了。

如果你把食谱的打印版留在某个地方，你的室友还有第四个选择。他们可以完成你开始做的事情！问题是他们不知道缺少什么。不像你划掉了每个已完成的步骤。他们最好的选择要么是给你打电话，要么是检查你所有的更改，以推断出缺少什么。

在这个例子中，厨房就像一个软件项目，用具是代码，食谱是正在实现的新功能。在公司的私人项目中，留下未完成的工作通常是不可行的，因为你要对你的工作负责，而且——在你需要离开的情况下——几乎可以肯定有人在跟踪/关注项目，所以他们避免出现“单点故障”。然而，在开源项目中，这种连续性很少发生。那么，在开源社区中，我们如何处理遗留的、未完成的代码，或者已完成但没有人敢于触碰的代码呢？

开源项目中的知识遗产

我们一直认为，开源是经验不足的软件工程师提高技能的最佳途径之一。对于许多人来说，开源项目提供了他们第一次使用特定工具的实践经验。版本控制系统、单元和 集成测试、持续交付、代码审查、特性规划、错误报告/修复等等。

除了学习机会，我们还可以将开源项目视为职业机会——社区中的许多资深工程师因此获得报酬，你可以将你的贡献添加到你的简历中。 这非常酷。没有什么比在学习的同时改进你的简历并引起潜在雇主的注意，这样你就可以支付房租更好了。

整个情况是一个人人都是赢家的无限循环吗？答案显然是否定的。这篇文章重点关注任何项目中出现的主要问题之一：公交车/卡车系数。在开源背景下，特别是当人们经历重大变化（如新工作或其他更私人的因素）时，他们往往会离开社区。我们将首先使用 OpenStack 作为示例，描述人们留下未完成的食谱可能引起的问题。然后，我们将尝试讨论一些想法来缓解这些问题。

常见问题

在过去的几年里，我们看到了 OpenStack 社区的许多变化，一些项目失去了一部分活跃的贡献者团队。这些损失导致了未完成的工作，甚至导致已完成的模块没有明确的维护者。以下是人们突然离开时发生的其他示例。虽然本文使用了 OpenStack 术语，例如“specs”，但这些问题很容易应用于一般的软件开发

• 文档损坏： 新的 API 或设置要么没有文档记录，要么有文档记录但没有实现。
• 难以解决的知识缺陷： 例如，新的需求和/或功能需要重构部分代码，但没有人具备必要的专业知识。
• 未完成的功能： 每个功能所需的缺失任务是什么？哪些任务已完成？
• 调试难题： 如果编写代码的人不在那里，这意味着需要花费大量的工程时间来解密——可以这么说——需要修复的代码路径。

为了说明这一点，我们将使用 项目树删除 功能。项目树删除是一个小功能，是我们中的一人三年多前提出的，但未能完成。基本上，主要目标是使 OpenStack 用户/操作员能够擦除整个项目分支，而无需手动禁用/删除从叶子开始的每个项目。非常直接，对吧？PTD 规范已合并，并具有以下工作项

• 更新 API 规范文档。
• 向文件 policy.json 添加新规则。
• 添加新端点以镜像新功能。
• 实现项目层次结构的新删除/禁用行为。

完成这些工作项的步骤顺序（路线图）是什么？我们如何知道从哪里开始，以及何时着手下一步？工作项之间是否存在任何逻辑依赖关系？我们如何知道从哪里开始，以及从什么开始？

此外，我们如何知道哪些工作已经完成（如果有）？我们所做的事情之一是查看 blueprint 和/或新的 bug tracker，例如

• 递归删除和项目禁用：https://review.openstack.org/148730（已合并）
• Reseller 的 API 更改：https://review.openstack.org/153007（已合并）
• 向 GET /projects 添加 parent_id：https://review.openstack.org/166326（已合并）
• 项目级联更新的管理器支持：https://review.openstack.org/243584（已合并）
• 级联更新的 API 支持：https://review.openstack.org/243585（已放弃）
• 项目级联删除的管理器支持：https://review.openstack.org/244149（已合并）
• 项目级联删除的 API 支持：https://review.openstack.org/244248（已放弃）
• 添加后端支持以删除项目列表：https://review.openstack.org/245916（已合并）
• 测试列表项目层次结构对于大型树是否正确：https://review.openstack.org/277512（已合并）
• 修复级联操作文档：https://review.openstack.org/274836（已合并）
• 还原“修复级联操作文档”：https://review.openstack.org/286716（已合并）
• 从文档中删除尚不支持的 API：https://review.openstack.org/368570（已合并）

在这里我们可以看到很多合并的补丁，但也看到一些被放弃了，还有一些标题中包含 Revert 和 Remove 字样。现在我们有强有力的证据表明这项工作尚未完成，但至少已经开始进行一些清理工作，以避免在服务 API 中暴露不完整的内容。让我们更深入地挖掘一下，看看 当前 删除项目代码。

在那里，我们可以看到添加了 cascade 参数（“cascade”类似于一起删除相关的东西，所以这个参数一定与提议的功能有关），并且它有一个特殊的块来处理 cascade 可能值的情况：

def _delete_project(self, project, initiator=None, cascade=False):

if cascade:
    # Getting reversed project's subtrees list, i.e. from the leaves
    # to the root, so we do not break parent_id FK.
    subtree_list = self.list_projects_in_subtree(project_id)
    subtree_list.reverse()
    if not self._check_whole_subtree_is_disabled(
            project_id, subtree_list=subtree_list):
        raise exception.ForbiddenNotSecurity(
            _('Cannot delete project %(project_id)s since its subtree '
              'contains enabled projects.')
            % {'project_id': project_id})

    project_list = subtree_list + [project]
    projects_ids = [x['id'] for x in project_list]

    ret = self.driver.delete_projects_from_ids(projects_ids)
    for prj in project_list:
        self._post_delete_cleanup_project(prj['id'], prj, initiator)
else:
    ret = self.driver.delete_project(project_id)
	self._post_delete_cleanup_project(project_id, project, initiator)

这个函数的调用者呢？他们是否使用了 cascade？如果我们搜索它，我们只在后端测试中找到出现

$ git grep "delete_project" | grep "cascade" | grep -v "def"
keystone/tests/unit/resource/test_backends.py:        PROVIDERS.resource_api.delete_project(root_project['id'], cascade=True)
keystone/tests/unit/resource/test_backends.py:        PROVIDERS.resource_api.delete_project(p1['id'], cascade=True)

我们还可以通过查看 删除项目 API 实现 来确认这一发现。

所以看来我们这里有一个问题，我很久以前开始的简单事情被遗忘了。社区或我如何防止这种情况发生？

从上面的例子中，最明显的问题之一是缺少明确的路线图和已完成任务的列表。为了跟踪实际的实现状态，我们不得不深入研究 blueprint/bug 评论和代码。

基于这个问题，我们可以勾勒出一个想法：对于每个新功能，我们需要一个路线图存储在某个地方，以反映实现状态。一旦路线图在规范中定义，我们可以将每个步骤作为 Launchpad 条目进行跟踪，例如，并更好地了解该规范的进度状态。

当然，这些步骤不会阻止未完成的项目，并且它们会增加一点流程，但遵循这些步骤可以更好地了解缺少什么，以便社区中的其他人可以完成甚至还原那里存在的内容。

这还不是全部

除了功能完成之外，项目的其他方面呢？我们不应该期望核心团队中的每个人都是每个项目模块的专家。这个问题突出了任何开源社区的另一个非常重要的方面：指导。

新人一直来到社区，正如我们之前讨论的那样，许多人有动力继续回来。但是，我们当前的社区成员是否愿意指导他们？你参加过多少次诸如 Outreachy  或 Google Summer of Code 等项目的导师，或者花时间回答项目聊天中的问题？

我们也知道人们最终会转向其他开源社区，所以我们有机会不留下我们学到的东西。我们可以始终将这些知识直接传递给当前感兴趣并积极提问的人，或者间接通过编写文档、博客文章、发表演讲等等。

为了拥有一个健康的开源社区，知识不能被少数人垄断。我们需要努力让尽可能多的人有能力推动项目前进。此外，指导的关键方面不仅与编码有关，还与领导技能有关。培养人们担任项目团队负责人、加入技术委员会等角色至关重要，如果我们希望看到社区在我们不在的时候也能发展壮大。

不用说，指导也是在大多数公司中攀登工程阶梯的重要技能。将此视为另一个动力。

总结

开源不应仅仅被视为达到目的的手段。协作是这些项目的关键部分，与指导一起，应始终被视为任何开源社区的首要公民。当然，我们将修复用作本文示例的未完成规范。

如果你是开源社区的一员，那么在你还在的时候，专注于分享你的知识是你的责任。很可能没有人会告诉你这样做，这应该是任何开源合作者的例行公事。

还有哪些其他分享知识的方式？你对这个问题有什么想法和建议？

这篇原创文章发布在 rodrigods。