项目众包开源项目_人们离开时保持开源项目的活力

项目众包开源项目

假设您有一天醒来，并决定最终使用您一直在社交媒体上观看的食谱视频。您获得了食材，整理了必要的器皿，然后开始按照食谱步骤操作。您将其切开，再切开，然后在将黄油和洋葱放入锅中的同时开始加热烤箱。然后，您的电话会提醒您：您与老板有个晚餐约会，您已经迟到了！您关闭所有设备并立即离开，在接近终点的地方停止烹饪过程。

几分钟后，您的室友回到家里准备吃晚饭，只发现厨房里正在进行的工作 。它们具有以下选项：

清理烂摊子，从头开始做饭。
点晚餐，不要费心做饭和/或修理剩下的烂摊子。
开始在剩下的烂摊子周围做饭，这可能会花费更多的时间，因为大多数餐具都很脏，而且厨房里没有多少空间。

如果您将食谱的印刷版本留在某处，则您的室友还有第四种选择。他们可以完成您开始的工作！问题在于他们不知道缺少了什么。这不像您划掉每个完成的步骤。他们最好的选择是打电话给您，或者检查所有更改以推断出缺少的内容。

在此示例中，厨房就像一个软件项目，用具是代码，而食谱是正在实施的新功能。在公司的私人项目中，通常不可以遗忘某些东西，因为您要对自己的工作负责，并且在需要离开的情况下，几乎可以肯定有人在跟踪/跟踪该项目，因此他们避免使用“单点故障。” 但是，对于开源项目，这种连续性很少发生。那么，我们在开源社区中如何处理遗留的，未完成的代码或已完成但没有人敢尝试的代码？

开源项目中的知识遗产

我们一直认为，开源是缺乏经验的软件工程师提高技能的最佳方法之一。对于许多开放源代码项目而言，它们提供了使用特定工具的首次动手经验。版本控制系统，单元和集成测试，持续交付，代码审查，功能计划，错误报告/修复等。

除了学习机会之外，我们还可以将开源项目视为职业机会-社区中的许多高级工程师都可以在那里获得报酬，并且可以将自己的贡献添加到简历中。太酷了。没有什么比在改善简历和吸引潜在的雇主关注的同时学习，因此您可以支付房租的了。

这是所有人都赢的无限循环吗？答案显然不是。这篇文章重点讨论任何项目中出现的主要问题之一：公共汽车/卡车因素。具体地说，在开源环境中，当人们经历重大变化（例如新工作或其他更多个人因素）时，他们倾向于离开社区。我们将首先以OpenStack为例，描述由于人们未完成其食谱而引起的问题。然后，我们将尝试讨论一些想法以减轻这些问题。

常见问题

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

损坏的文档：没有记录新的API或设置，或者有记录但未实现。
难以解决的知识缺陷：例如，一项新的要求和/或功能要求重构部分代码，但是没有人拥有必要的专业知识。
不完整的功能：每个功能需要缺少哪些任务？哪些任务已完成？
调试过程：如果编写代码的人不在场，这意味着解密（可以这么说）需要固定的代码路径需要大量的工程时间。

为了说明，我们将使用“ 项目树删除”功能。项目树删除是我们一个人三年多以前提出的一项微小功能，目前还无法完成。基本上，主要目标是使OpenStack用户/操作员能够擦除整个项目分支，而不必从叶子开始手动禁用/删除每个项目。很简单吧？ PTD规范已合并，并包含以下工作项 ：

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

完成这些工作项的步骤顺序（路线图）如何？我们如何知道从哪里开始，什么时候下一步要解决？工作项之间是否存在逻辑依赖性？我们怎么知道从哪里开始？

另外，我们如何知道哪些工作已经完成（如果有）？我们要做的一件事是查看蓝图和/或新的错误跟踪器，例如：

递归删除和项目禁用： https ： //review.openstack.org/148730 （合并）
转销商的API更改： https : //review.openstack.org/153007 （合并）
将parent_id添加到GET / projects： 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 （已合并）

在这里，我们可以看到很多合并的补丁，但也有一些被遗弃，并且在标题中包含“还原”和“删除”一词。现在，我们有充分的证据表明该工作尚未完成，但是至少已经开始进行一些清理工作，并避免在服务API中暴露不完整的内容。让我们更深入地研究一下当前的删除项目代码。

在那里，我们可以看到一个附加的级联参数（“级联”类似于将相关内容一起删除，因此该参数必须与建议的功能有某种联系），并且它具有一个特殊的块来处理级联可能值的情况：

 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 )

那这个函数的调用者呢？他们是否完全使用级联？如果我们搜索它，我们只会在后端测试中找到出现的情况：

$ 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 )

我们还可以通过查看delete projects API实现来确认这一发现。

因此，似乎我们在这里遇到了问题，很早以前我就抛弃了我开始做的一些简单事情。社区或我如何阻止这种情况的发生？

在上面的示例中，最明显的问题之一是缺少清晰的路线图和某处已完成任务的列表。为了跟踪实际的实现状态，我们必须深入研究蓝图/错误注释和代码。

基于此问题，我们可以概述一个想法：对于每个新功能，我们都需要将路线图存储在某处以反映实现状态。一旦在规范中定义了路线图，我们就可以将每个步骤作为启动板条目进行跟踪，例如，可以更好地查看该规范的进度状态。

当然，这些步骤不会阻止未完成的项目，并且会增加一些过程，但是遵循这些步骤可以更好地了解缺失的内容，以便社区中的其他人可以完成甚至恢复存在的内容。

`那不是全部`

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

正如我们之前所讨论的那样，新人们一直都在社区中生活，许多人都有继续返回的动力。但是，我们目前的社区成员愿意指导他们吗？您作为导师参加了诸如Outreachy或Google Summer of Code之类的程序多少次，或者花了一些时间来回答项目聊天中的问题？

我们还知道人们最终会转向其他开源社区，因此我们有机会不遗余力。我们始终可以通过编写文档，博客文章，发表演讲等方式，将这些知识直接传递给当前有兴趣并积极提出问题的人员，或者间接传递给那些对此感兴趣的人。

为了拥有一个健康的开源社区，知识不能被少数人支配。我们需要努力使尽可能多的人有能力推动该项目向前发展。另外，指导的一个关键方面不仅与编码有关，而且与领导技能有关。如果我们希望即使社区不再生活，社区也能成长，那么让人们做好担任项目团队负责人，加入技术委员会等角色的准备至关重要。

毋庸置疑，在大多数公司中，指导也是攀登工程阶梯的一项重要技能。考虑另一种动机。

`总结一下`

开源不应该仅仅是达到目的的手段。协作是这些项目的关键部分，除了指导之外，在任何开源社区中都应始终将协作视为第一位公民。而且，当然，我们将修复本文示例中未完成的规范。

如果您是开放源代码社区的一部分，则有责任在您仍在时专注于共享知识。可能没有人会告诉您这样做，它应该成为任何开源协作者例程的一部分。

还有什么其他分享知识的方式？您对此问题有何想法？

最初的这篇文章被张贴在了棒虫上。

翻译自: https://opensource.com/article/19/5/code-missing-community-management

项目众包开源项目