Node.js 过去一年的重点是增加参与该项目的贡献者数量。Node.js 的用户增长率连续几年保持 100% 的同比增长，但贡献者的数量一度实际上在下降。
经过一年多的社区建设和迭代，我们现在比以往任何时候都更健康。该项目已经重组，划分为许多组件，目前有 400 名成员。在构成项目整体的大多数代码仓库中，我们看到每个月约有 50% 的贡献者是该代码仓库的新手。这意味着我们将用户转化为贡献者的比例是我们用户社区增长速度的六倍。贡献者对于开源项目的健康和长久发展至关重要。
我们已经学到了很多，并准备分享，这不仅包括帮助扩展人力基础设施的工具，还包括文化和核心价值观：透明度、参与性和有效性。我们相信，这些理念和实践最终将在未来几年塑造开源的未来。
首先，让我们从词汇表以及我们如何定义构成我们社区的人员开始。
谁是您的社区？
- 使用该软件的人员：用户。
- 为项目做贡献的人员：贡献者。
- 做出决策的人员：领导者。
人们如何成为用户、贡献者和领导者？
- 人们尝试使用您的软件，并在学习过程中寻找资源来帮助他们了解更多信息。
- 用户寻求做出改变，完成贡献过程，并选择再次贡献。
- 贡献者在项目贡献中投入了足够的精力，他们被视为决策者，并被赋予这些决策的共同所有权。
您如何将人们转化为用户，将用户转化为贡献者，并将贡献者转化为领导者？
- 通过教育创造更多用户。
- 通过宽松的贡献政策鼓励用户贡献。
- 通过参与式治理赋能更多领导者。
为了使这些计划能够运作并维持自身，它们需要平衡以下要素
- 参与
- 透明度
- 有效性
教育
教育不能被视为技术问题。您不能像解决代码问题那样创建一个单一资源来解决这个问题。我们常常认为，其他人会通过遵循我们所遵循的完全相同的路径来学习如何使用特定技术。不幸的是，这是教育更多用户最糟糕的方法。人们来自不同的背景，处于他们生活和职业生涯的不同阶段。为了让他们选择学习如何使用您的软件，并继续成长和提高他们的使用率，他们需要他们感到舒适并能引起共鸣的资源。与其尝试引导他们通过我们用来学习的路径，不如看看他们是如何学习他们感到舒适的技术的，并为他们提供类似的资源。这意味着您需要各种各样的教育资源，从 API 文档、博客文章和研讨会到传统的培训计划。
这些资源彼此之间不是竞争关系，它们是互补的，只要它们以开放和面向社区的方式完成。这正是我们仍在努力的方向，因为它实际上永无止境，但您可以看到 NodeSchool 对 Node.js 社区的影响。通过 NodeSchool，您可以下载研讨会并在家完成，并且有一个代码仓库，您可以在其中记录问题以获得帮助（如果需要）。同时，NodeSchool 社区在全球拥有数百个本地分会，这些分会运行小型本地实践研讨会。许多人在没有一些面对面的帮助的情况下无法克服最初的学习曲线。每个本地分会还在每个研讨会上为参与者建立了一个专门针对其本地分会的代码仓库，他们可以在未来继续在其中提问。NodeSchool 最终以这种方式吸引了两种截然不同的入门级用户，并且一直是发展我们社区的巨大资源。
转化
用户转化为贡献者，以及贡献者转化为领导者的数量，取决于将他们从一个级别转化为下一个级别。虽然大多数项目都将他们缺乏贡献者或领导者描述为“管道问题”，但这些几乎总是“转化问题”。在开源中，您的用户通常是开发人员。他们要么已经具备以某种方式贡献所需的技术能力，要么只需稍加教育就可以轻松获得。转化他们只是降低入门门槛的问题；学习贡献所需的工具和流程，并设计一个鼓励和留住贡献者的审查和发布流程。
GitHub 在降低这些门槛方面做了很多工作。现在有一个单一的工具链，可以从修改软件，到将其发送到该项目，到被几乎所有现代开源项目接受。得益于 GitHub，这些技能在项目之间也具有高度的可移植性。然而，项目之间仍然存在许多主要差异，例如代码如何合并、需要哪些元数据（如果有）、提交权限的获取以及贡献完成后整个软件的发布过程。当涉及到用户到贡献者的转化时，这些政策解释了项目之间一些最大的差异。
在 Node.js 项目中，新的贡献者约占每月所有贡献者的 50%。考虑到 Node.js 用户增长率约为每月 8%，这是一个惊人的数字。我们的贡献率不仅仅是 Node.js 总体增长的产物，而且是我们所谓的宽松的贡献政策的实际胜利。
宽松的贡献政策
几年前，Rod Vagg（现在的 Node.js TSC 主席）开始为 levelup 试验一项新的贡献政策。他称该政策为 开放的开源项目，其本质是
- 每一项贡献，即使来自提交者，都必须是一个拉取请求，并且必须有足够的时间供其他提交者审查。
- 每一项成功的、大于几行的贡献都将导致贡献者被授予提交权限。
这与许多开源项目中传统的做法大相径庭，传统做法是将提交权限仅限于少数开发人员。这些现在过时的政策起源于版本控制系统，这些系统比 git 更不能容忍错误。在 git 中，很难犯下无法被其他贡献者修复的重大错误。这意味着在 GitHub 时代，授予提交权限可以更加自由化。获得提交权限也充当了一种承诺机制，特别是对于开源新手贡献者而言，因为它为参与者提供了他们对项目拥有共同所有权的切实证据。
添加更多提交者意味着添加更多代码审查者，这反过来又简化了处理更多贡献者的过程。当然，每个项目都是不同的。适用于 levelup 的确切流程不适用于每个项目，事实上，也不适用于 Node.js Core，但促使它产生的价值观导致了 Node.js 项目中各个工作组和代码仓库的几项宽松的贡献政策的创建。在设计这些流程时，我们确定所有成功的政策都是参与性、透明度和有效性这三个价值观之间的平衡。这些价值观不是绝对的，您通常不能 100% 参与，同时又 100% 有效，但通过根据具体情况平衡权衡，您最终会获得惊人的转化率，这将继续发展您的项目并保持其健康。
举例来说，Node.js 网站和 Node.js Core 的贡献政策截然不同。在 Node.js Core 中，提交会落在 master 分支上，master 分支是 Node.js 未来尚未发布的版本。然后，贡献会按提交逐个 cherry-pick 到当前版本、LTS 版本和维护版本的各个分支。如果没有干净的 squash 提交和清晰的提交消息元数据，这就不可能实现。因此，提交者不能使用 GitHub 合并按钮，并且经常需要手动承担额外的工作。这当然是参与的障碍，但为了项目的有效性，这是必要的。但是，这些技术要求在网站上不存在，网站上的每次合并都会导致 master 分支的新部署。因此，网站的贡献政策允许提交者使用合并按钮，并且不需要 squash 提交或添加到提交消息的元数据，这降低了新贡献的入门门槛。通常，开源中的流程会成为新开发人员的入门门槛，我们采取了一些基本方法来确保这些政策鼓励贡献而不是充当威慑。
- 在任何可能的情况下，为最小的临时贡献者而不是最活跃的贡献者设计流程。
- 每个贡献的默认路径都应该是落地。讨论、审查和合并过程应设计为将贡献移至落地路径的更正。一旦没有更多更正（异议），更改应在没有进一步流程的情况下落地。
- 使尽可能广泛的贡献者群体能够合并达成轻松共识的补丁。领导层应采用治理流程，促进和升级贡献，并成为每个贡献所需的印章。
- 始终寻求共识，但如果您陷入僵局，请升级到领导层进行决策，以便继续前进。
隐藏的文化入门障碍
由于各种 Node.js 代码仓库在不同的政策下运行，您可能会认为这些差异会成为跨代码仓库贡献和参与的障碍，但我们发现事实恰恰相反。事实证明，隐藏的文化入门障碍通常比任何技术障碍都大得多。因此，许多贡献者从更接近甚至低于他们现有技能水平的工作组开始，随着时间的推移，我们看到许多这些贡献者在其他工作组甚至 Node.js Core 中承担更深层次的技术任务。
对于某些人来说，为开源做贡献比其他人更容易。人们非常害怕因为做错事或只是不合群而被责骂。这些情感需求是项目最难解决的问题之一，但通过为贡献者提供一个技术水平要求非常低的地方来贡献（文档、网站内容 markdown 等），您可以大大降低这些担忧，并且至少消除与他们自我感知的技术能力相关的担忧。一旦人们在一个工作组中感到舒适，他们对其他工作组甚至 Core 的担忧就会大大降低，因此，我们看到从本地化工作组和网站迁移到 Core。
我们在宽松的贡献政策中看到的成功打破了我们在许多开源项目中看到的错误说法，即一个项目根本没有足够的“合格”或“熟练”开发人员来采用更具参与性的结构。并非没有足够的潜在贡献者，而是潜在贡献者不想将时间花在缺乏适当参与激励措施和保留一些已建立的提交者可能不害怕的巨大入门门槛的项目中。
参与式治理
贡献者共同承担项目的责任，在这些人中，您会找到一群领导者，贡献者信任他们进行决策。参与式治理的目标是确保贡献者信任的决策人员实际上被授予了该决策的自主权，并尽可能地分配责任而不是集中责任。在整个 Node.js 项目中，我们有由 TC（技术委员会）管理的顶级项目 (TLP)。Node.js Core 是一个由 CTC（核心技术委员会）管理的顶级项目。
正如我们之前讨论的那样，该小组是贡献者在无法达成共识时的升级机制，这意味着大多数决策实际上是由贡献者共享的，并且永远不会到达 CTC。只有在极少数情况下无法达成共识时，才会将其发送给 CTC。CTC 还将许多职责委托给称为工作组的子组。这些工作组有自己的治理结构和一组贡献者。他们不向 CTC 报告，CTC 成员无权对其委托给这些工作组的任何事项拥有决策权。这种更无政府主义的方法分配权力而不是将其集中在传统的等级结构中。像 CTC 这样的顶级项目 TC，也有一些基本的治理规则来保护项目免受不当影响。
- 寻求共识用于决策，在无法达成共识时，以多数票作为打破僵局的方式。
- TC 中隶属于同一家公司的成员不得超过 25%。
- TC 必须有来自至少四个时区的代表。
寻求共识一直是该项目的非常有效的工具。它鼓励人们共同努力并达成协议，并且它不会像纯粹的共识那样奖励顽固分子或偏袒不作为。纯粹的共识就像赋予每个人对任何更改的否决权，当参与者不希望发生某些事情时，他们几乎没有动力来说服他们的同龄人。通过在无法达成共识时退回到投票，这意味着任何反对更改的人都必须像赞成更改的人一样努力说服他们的同龄人。
结果令人难以置信，因为我们实际上从未因缺乏共识而被强制投票。这并不是说我们没有分歧，但我们总是能够找到创造性的妥协方案。最后但并非最不重要的一点是，所有决策都在 GitHub 上做出。这种透明度对于将贡献者转化为领导者（未来的 TC 成员）至关重要，因为他们可以看到流程的进行。CTC 每周都会召开一次电话会议，以便每个人都必须就任何有争议的问题做出决定，以便贡献者可以继续前进。只有在 GitHub 上进行了漫长的贡献者讨论之后，这些问题才能升级到 CTC。会议通话也被录音和发布，并附有详细的会议纪要，大多数（如果不是全部）工作组会议也是如此。
价值观 > 流程
大多数已建立的项目都喜欢向新项目指定一个特定的和首选的流程。当我们开始考虑接纳更多项目加入 Node.js 基金会时，我们发现许多其他基金会为所有加入的项目规定了一个流程。我们无法让自己这样做。我们是一个年轻的项目，我们今年才刚刚弄清楚对我们有效的政策，所以没有人真正感到可以如此规范。
相反，我们开始更深入地思考为什么这些政策有效，以及我们创建这些政策的一些假设价值观是什么。结果是一个孵化过程，旨在指导和确保一个采用参与性、透明度和有效性价值观的流程，而不是将特定的外国流程强加到他们的项目中。
现在，我们正在与开源世界的其他地方分享这些价值观和最佳实践，希望这对您们也能像对我们一样有效，并且我们可以在开源世界中就如何让人们更深入地参与我们的社区进行更多的思考和讨论。
评论已关闭。