关于开放协作的一些思考

1 前言

Rust 是一个开源项目，不仅仅是开放源代码，更意味着该项目的工作是公开、包容的，并需要和更加广泛的社区相互协作。但是，有时候这样的工作是非常困难的，尤其是那些会激起许多人强烈反应或超过大多数人的工作经验的工作，表现的更加明显。制定策略和治理规范就是这样的两种情况，尤其需要公开的推进这样的工作是非常非常困难的！特别是主要具有技术背景的人从事这样的工作的时候更加困难。我自己就试过很多次这样的工作，结果都不是很好。

最近，我觉得目前 Rust 项目在制定项目治理规范和商标的策略的工作没有达到预期的开放协作的标准。自己亲身参与这些工作的同时，也在试图找出为什么会出现这样的情况的原因，但结果不尽人意，尤其自己在过程中，有时候也没达到自己对友好和同理心的要求。因此，我尝试换一个角度，写下我理解中推进这些工作的正确步骤，以及如何确保成功推进这样工作的想法。很多时候，说起来容易，但是做起真的很难，即使我们知道行动的目标和步骤，实践起来也是很难的。我希望这篇文章能够对此有所帮助。虽然我在尝试做这些事情时失败的次数比成功的次数还要多，但希望你们可以从我的错误中学到经验，吸取教训。

2 开始之前

在开始之前就做正确的事情也是很难的！尽管以公开的方式制定策略规范，比起私下推进需要投入的更多，需要更多的努力，但是你必须这么做！如果不公开地去制定策略，就没办法达到想要的结果，同时还会激起人们的情绪，会让整个社区变得糟糕。保持公开是这个工作的必要部分，虽然会导致工作花费更长的时间，也需要在工作上投入更多的感情。但是从长远来看，保持公开是最好的选择。这就像是写程序需要写测试、写文档，早上需要刷牙一样，你必须这样做。

此外，这件事情没有什么捷径。如果你只是私下分享你的工作结果，那么你是错的。你必须主动进行沟通，并确保你的沟通是良好的。除了主动沟通，你还需要进行协作。

我经常看到许多人将这个工作流程严格定义为两类：一种是绝对公开的，例如将所有工作内容都在一个公开的仓库中公开，希望将整个世界的所有人都参与进来；另一种是秘密的工作，只偶尔发布一些工作结果以及一些调查问卷。使用第一种流程无法推进大规模工作，会导致整个过程十分混乱并产生不可预测的结果。因此，在实际工作中，我们应该避免这种情况。同时，第二种工作流程也是不可取的，因为整个流程不符合开放工作的精神。这样的流程就像一些项目，私下写代码，写完后直接公布结果，然后美其名曰“开源”。整个过程社区没有参与，没有贡献。

我认为正确的方式是在适当的私有范围内进行工作，每个工作阶段都有意识地让特定范围的社区人员参与其中。

首先，我将介绍一些有用的概念，以及我认为必须遵守的原则。

2.1 WWIC?

Why wasn't I consulted? (为什么没问过我？)

Paul Ford 将这个问题称为“网络的根本问题”。Aaron Turon（这个链接的演讲非常好，建议观看）在 Rust 中推广了这个问题作为一种思考社区协作的方式。我也认为这是推进这类工作的一个非常重要的视角。

人们希望被赋予权力，并希望他们能够参与其中。这是因为人们不想被忽略，不想总是思考“为什么没有问过我”的问题。

这个口号背后的理念催生了 RFC 流程及其早期的演变，并催生了 Rust 项目的开放开发的方式。真实的情况是并不是每个人都有平等的投票权，而是每个人都觉得自己真正地参与进来，得到了尊重。

2.2 RACI

RACI是 Responsible（执行人）, Accountable（责任人）, Consulted（需要咨询的人）, Informed（需要通知的人）”的首字母缩写。这个是一个用来识别哪些人应该参与进来的思考框架。就像许多其他概念一样，这个概念可能会被过度强调而导致整个流程变得死板或者是令人不舒服，但是如果我们能够理性的使用，这个概念将会挥发很大的作用。这里我对这个概念的理解和描述可能会和一些在学院里老师讲的有些区别。这个概念还有一些其他的解释，如果有兴趣可以自行搜索查阅。

按照 RACI 框架可以将人分成一下四类：

• 具体执行人（Responsible）：负责完成工作并确保交付的人员；
• 统筹责任人（Accountable）：确保工作完成并且正确的人（通常是公司领导或高管）。有时这可能是 R（Responsible）团队的领导或 R 团队的一部分成员，但我认为最好不要这样做。R 团队和 A（Accountable） 团队会密切合作，但是 A 团队应该具有“外部人”的视角来审视整个工作；
• 需要咨询的人（Consulted）：对工作有利益关系和可提供有用意见和反馈的利益相关者。这个团队应该相对较小，以便他们可以提出有效的建议。咨询意味着他们会参与到在方向制定和许多工作细节方面。我认为，让 C（Consulted） 组成为最终用户或客户是一种反模式；你可能需要这些人的意见，但不需要与他们进行合作；
• 需要通知的人（Informed）：应该被通知有关过程的人员。请注意，这不仅是通知工作结果，而是通知整个工作过程本身。在公司里，范围可能是同级团队、高管或法律部门等（不是一般大众，甚至不是整个公司范围，他们可能只在产品发布或其他什么时候被告知）。你不是必须从这个团队获得反馈，但如果有反馈，你应该听取而不能直接忽略。你可能偶尔需要通过 +1/-1 投票的方式来确保你目前的方向是正确的。

一些常犯的错误：

• R 团队中人数过多，这个有可能带来很多额外的负担最重导致工作无法完成。
• 没有区分 C（Consulted） 团队和 I（Informed）团队，这样会带来过多的干扰，可能会忽略掉真正需要被咨询的人。
• I（Informed）范围太大，这样会将对一个真正项目感兴趣的人（应该属于 Is）和任何稍微有兴趣的人混为一谈（这些人不应该属于 Is，但仍应该偶尔得到通知或类似信息）。

2.3 一些其他规则

不同的人关心不同的事情。有些人会说他们想“参与到这个工作中”，或者应该被“被咨询”或“告知”。这些词有着许多不同的含义，也代表着他们在这个工作中扮演的角色是不一样的。

有些人不仅仅关心结果，还会关心细节和过程至少有些人是这样的）。不要假设人们不关心无聊的细节，或者假设只有结果才重要。人们关心的是这个工作是否是以正确的方式完成的。

问责制很重要，信任是自己争取来的。在一个开源项目中，问责意味着参与的人是明确可追查的（即使使用化名也是被允许的）。外部人员可以知道是谁提出了具体的想法和决策，而不是直接将决策权和责任归咎于整个团队。这意味着每个错误都可以找到负责人。这也意味着大家清楚地知道谁有这个权力以及为什么他有这个权力。

通常会有很多人想要更多。例如，有些人想更多地参与到某一项工作，比如更多的被询问，甚至想拥有否决权，但他们只是众多参与者之一。开放协作并不意味着每个人在这个过程中都具有同样的角色。当出现这种情况时，你需要坚定而明确地拒绝他们，并给出拒绝的原因（可以使用效率低作为拒绝的原因，但不要过度依赖这个解释）。人们通常希望获得更多参与的机会，这需要通过他们不断提供有效的输入来逐渐建立相互信任的，并不能一蹴而就。

3 如何去做

沟通是关键！需要进行大量有目的的沟通，包括单项的通知以及双向的交流。下面是一些开放项目中常用的沟通方式：

• 公告（在博客帖子、论坛帖子、邮件列表、新闻稿等中），有助于广泛传播信息，确保这个工作广为人知；
• 时事通讯和发行说明，适合正式的摘要，适用于那些想要密切关注整体进展的人；
• 博客文章，有助于提供额外的信息，方便人们了解可能的解决方案/一些想法/以及思考的过程；
• 会议记录/会议记录/录音，适合那些想要密切跟踪项目或需要详细背景信息才能参与贡献的人，有助于展示工作的透明度和建立相互信任；
• 公开工作。

上述的最后一点是公开工作。对于代码来说，在公开的仓库工作是默认的选项。对于制定策略或者一些类似的工作，也是同样的。如果你能做到这一点，你依然需要进行额外的沟通，因为不是每个人都会关注 repo，即便是关注 repo 的人，他们也不是只通过获取 commits 和 discussion 很好的获取工作的进展。如果你没能做到这一点，那么你需要做更多其他的工作去保证你的工作足够的公开和透明。

在项目的早期，你需要清楚的规划好哪些内容需要保密，哪些内容可以公开的。涉及到私人信息或者私密的内容需要保密（如涉及到一些公司的的财务和法律问题，但如果只涉及公开实体的财务或法律问题，则不一定需要保密）。一些敏感的工作（如审核、调解、一些私下指导等）也应该在私下完成。另外一些其他的工作，提起来可能觉得需要私下进行，比如治理工作、制定法律规范等，但实际上这些工作很少是需要保密的。虽然你的律师并不想做 PR，但是你仍然可以进行许多公开的工作。如果你能非常明确的表达你想要的互动方式，并又意识去沟通，并且让人们意识到他们随时可以退出，另外你又愿意承担起组织讨论的事情，其实公开工作远比我们想象中容易很多。在我看来，有一定限制的公开工作比起私下工作，然后在进行额外的工作去弥补问题，是更好的方式。虽然短时间内会投入更多的感情进去，但从长远来看，会减轻你的工作压力并且会产生更好的结果。

无论你是在进行公开或者私下工作，你都需要在你工作的每个阶段都和社区保持联系，寻求他们对你的工作的建议。我看到人们犯的最大错误是在获取输入后，然后就是准备一份草案去收集反馈。也就是说，整个工作的推进过程或者开发过程是黑盒子，只是有输入和输出。这不是开放式的协作！为了开放，社区必须能够帮助确定工作的方向和目标，能够影响到你的设计并参与贡献，而不仅仅是最后完善你搞出来的结果。

一个故事：你和一群朋友要去旅行。大家都同意你来组织行程并负责开车。下面是一个好的工作方式的例子：

• 你（自己）找了一些距离合适的目的地，并根据不同目的地的优缺点缩小目的地的选择反问
• 将你选择的这些目的地信息发送给大家，让他们提前了解到这些信息
• 然后你约大家一起见个面或者喝个咖啡，告诉他们你之前列的候选目的地，每个目的地可以做的事情和去目的地的油费等，并拉上大家一起讨论，最后商定一个目的地。
• 你给车子加满油，然后给 Alice 个清单去购买一些必需品。
• 然后在通知大家你们已经准备好出发了。
• 大家聚在一起，你开车带着大家出发。
• 路中，你走错路了，让 Bob 负责查看地图，指导你路线。
• 过了一会，你感觉到累了，就让 Charlie 来替你开一会车。
• 到了目的地后，发现营地关门了，你找了一些备选方案，并和大家一起讨论去哪住宿。

一些不太好的做法：

• 大家告诉你他们这次旅行的偏好，然后你选择了一个目的地，但是你没有告诉大家你最后选的目的地是哪就出发了。离目的地还有一公里的时候，你才告诉大家你们这是要哪。结果就是有些人将沙滩装备带到了滑雪场，还有就是由于你只问大家想要的活动，没有问大家喜欢吃什么，你们中有一半是吃素的，然后你组织了一场烤肉聚餐。
• 你们组织大家一起讨论目的地。大家没有范围的推荐目的地，但又都不知道如何去那里或需要花多少钱。
• 每个人都开着自己的车，花了更多的钱，最终到达了不同的目的地。
• 你独自做出所有的决定。你给小组成员发了你自己精心准备的计划，以及选择这个目的地的理由。到达目的地后，你又给每个人分配了一个时间表，计划他们的时间每分钟做什么，谁和谁一起玩，何时上厕所。每顿饭吃什么，即使你选的餐厅很合适，食物也会美味，但是整个旅途中其他人没有一点选择的自由。你为每一餐挑选了合适的葡萄酒，当有人说他今晚更想喝啤酒时，你崩溃了，你把他直接踢出了旅行团。

抱歉，有点跑题了。下面回到你应该做的事情上。

4 时间表

4.1 开始前

在项目开始之前，需要公示你想要做什么，以及为什么要做。并在公告中阐述你的目标和这个项目的范围。根据你在社区中的角色和想要做的事情的类型，可以选择正式或者非正式的公告。另外这个公告需要在认证的贡献者和维护者中公开，而不是对整个世界都公开。你需要从认证贡献者和维护者们获得反馈，确保整个工作值得做，并且确保你的目标和整体方向是正确的。

寻找志愿者。谁来负责具体工作以及如何招募这些人非常关键。如果你只是定向的要求而不是公开的招募，那么你就会延续裙带关系，并牺牲了人员的多样性。你的工作也就不够开放，也会让整个社区感觉你和你的工作不够开放。除了哪些显而易见的群体意外，你还应该邀请志愿者加入 C 组和 I 组。（尽管这些组的成员通常是显而易见的，特别是 I 组经常是整个社区）

另外你需要对不同的角色提出特定的要求，并不是意味着任何人都可以随意领取特定的任务。特别是需要明确这个工作意味着什么（工作的类型、需要多少时间投入等）、需要多少人、以及需要的技能和经验。并且志愿者需要在社区中具有一定的认可度，获得大家的信任。你要有对志愿者说“不“的准备。另外明确的和志愿者们说清楚，可以以很多角色参与到项目中来，不仅仅是 R 组成员，也可以成为是 C 组的成员（避免志愿者害怕错过这个项目）。

4.2 开始做

一定你确定了参与项目的人员并获得官方的许可（这影响到 A 组的人员），接着你就应该宣布你们的工作开始了。整个公告应该是一个通知性质的，而不是用来寻求反馈的。并且这个公告的链接应该是可访问的，这个在后续的沟通中会用到。你应该在这个公告中说明这个项目的目标和范围，这些内容可能是在之前的讨论中确定下来的，也可以在后续的项目推进中不断的迭代。另外需要说明公告中内容的阶段，是已经确定的还是后续会发生变化，并且告知大家如何参与到这些内容的讨论中来。

你应该宣布 RACI 组（特别是R组）的任务，这里你不一定使用 RACI 说法，也可以自己定义不同的角色范围。另外你应该明确 I 组（可能是公开的）该如何跟进项目的进展，以及你会在何时以及用什么方式咨询 C 组。最重要的是要明确你们会在何时征求反馈或是大家是否有其他反馈机会。

你应该描述 R 组将如何工作。特别是需要说明哪些方面的工作将会公开和哪些工作将不公开，以及这样做的原因。

4.3 进行中

当你正在集中精力在一些里程碑的工作上时，突然暂停下来进行交流讨论，这个可能是一个很痛苦并且困难的事情。但是对于开放协作来说，这是必不可少的。工作是一个过程，而不仅仅只有一个结果，所以如果想要真正的做到开放，你必须分享你的工作过程，而不是简单的把结果发出来。即便是你觉得整个工作的过程可能是无聊的，没有什么特定情况，但是你还是需要分享出来！可能你觉得无聊的过程，其他人看来可能是乐趣无穷，而且去证明一个事情是无趣的整个过程可能也是一个充满乐趣的过程。

里程碑是必须的，你的团队应该设定小的里程碑，并且不断的快速迭代。此外这些里程碑应该是针对于工作本身的里程碑，而不是只是为了方便交流随意设定的日期（保持工作进展和交流的频率一致）。这就像软件发布一样，这些里程碑可以是基于时间，也可以是基于功能进展的，但是不能混合起来。

在每个里程碑上，你应该更新工作进展，并寻求反馈，还应该包括工作的时间安排或是团队人员的变更，下一个里程碑的计划，社区参与的方式，如果工作目标或范围发生变更，也应该在里程碑上公开。里程碑的主要目标是让人们了解情况，同时也是检查你是在一个正确的方向上，检查你之前的规划是否合适，检查你是否是在用一个可持续的方式在推进工作。

除了里程碑以外，你还应该进行额外的沟通交流。比如团队成员发布的非正式博客文章，他们在博客中会提及到他们的当前的想法和正在做的事情，这些对项目的公开和提供额外的交流非常有用。在额外交流方便，Rust 项目在技术相关的话题上做的很好，但是对于一些非技术的话题上却不尽人意。另外不要在意出现重复沟通或者内容重复的情况，比如你可能会在个人的博客上、官方博客、时事通讯或者是会议记录上都提到相同的内容，这没啥关系，毕竟不同的人关心的内容或是阅读的习惯都是不一样！

另外你应该积极的主动分享工作文档的草稿（准备好后），即便是文档的内容还不够完善，你也应该尽早的分享出来，同时要清楚的表明这个文档预期还需要迭代几版。这样做你可以确保你能够及时的和正确的人（C 组）寻求反馈，并在适当的时间和以适当的方式提出你的请求。每次分享工作时候，你都应该重新阐述你的工作目标和范围，为什么要做这个事情，以及为什么（以及如何）共享这个内容有助于达成最后的工作目标，另外还可以说明后续这个工作还会产生的其他成果，避免人们对你的工作产生额外的成果期待。虽然这些可能是显而易见的，但是你不能排除有些人是第一次看到这些内容（不能排除会有新的成员加入进来）。总的来说，人是非常懒惰的，很多时候甚至懒得点进链接去理解背景，所以你需要不断的重申这些内容。

另外你需要清楚表明需要的反馈类型：有时候一个 +1 / -1 的投票就足够了，有时候你需要详细的反馈。可能有些人对你提供的反馈渠道不满，或者他们想要反馈更多的内容，那么有可能你对他们的分组（C vs I）于他们自己的认知没有达成一致，又或者他们可能只是错了。

在分享之前，让 R 组以外人的提前看一遍你分享的内容很有必要，这样可以确保对于 R 组以外的人也能看明白你分享的内容。一个 A 组的人可能适合这项工作，或者只是找你你信任的朋友或同事。但需要注意，如果你一直让同一个人进行这项工作，那么他们就不再具有外部人士的视角，因此你需要询问新的人。

4.4 发布

理想情况下，最后的发布并不是一件大事。你在之前的不断迭代和沟通中已经将大部分的工作成果分享出来了，因此在最后的发布中，也只是将涉及的人员范围进一步扩大。在交付成果的时候，唯一没有看到工作内容的人是社区外部的人或者事那么只是随意关注的人。已经有足够的人参与到你的工作过程，最后的结果也会是符合预期的，毕竟每个你需要咨询的人，在你整个工作的过程中都涵盖到了，他们也会对能够参与到了整个工作的过程感到满足。

你不能在开放协作的过程中，发布你的工作成果（指不能对合作者发布，可以发布给客户/用户。对于谁是合作者，谁是客户，你需要和社区达成一致，如果有人认为他们是合作者，但你错当作是一个普通用户，那么这样可能导致灾难性的后果）。你不能私下准备一个“草案”，然后直接发出来希望收到反馈，如果你是通过这样的方式进行合作，即使人们感受到了被咨询或者参与进来了，但是结果注定是失败的！

如果你发现你正朝着发布目标努力工作，并且打算等到发布结果的时候在寻求反馈意见，那么现在你就需要停下来！你必须进行沟通、协作并迭代你的工作！

如果最终发布的结果是一个决定，那么你需要一小群可信赖的人来共同做出决定（这可能需要在私下进行）。重要的是，在做出决定之前，前期的准备工作必须完成，比如调研，准备文档等。你不能在一个开放的过程中把准备工作以及决策混在一起。这就是 Rust 项目 RFC 提案的 “no new rationale” 原则。如果最后的决定是可以公开决定并且可迭代的，那么你就应该这样做，公开的确定最后的决定并不断的去迭代。

另外我认为我们需要避免反馈的循环增长。如果某个人的反馈在发布的时候是有意义的，那么如果你能在工作开始的时候就咨询他的意见，意义会更大。一开始你意识到某些人的意见可能会对项目有帮助，那么就应该尽早的咨询他的意见，并让更多的人了解到你们的进展。否则到最后，你们咨询的范围会变小，同时需要投入更多的精力去处理反馈，甚至会发现自己从一开始就错了！

另外，明确说明这次发布后，如何推进/维护/达到下一个版本，也会让发布结果更有效，更加容易。你可以通过说明开放协作将继续进行，从而减少了达到完美和持续迭代的压力。如果你这在之前的开发阶段，已经建立了大家对开放性的信任的情况下最有效。

5 结论

说总是比做容易很多，但是还是希望这篇文章能够对你有所帮助。

具体到 Rust 项目，我认为重要的是朝着非技术工作的 RFC 流程的精神前进（不一定是程序细节，而是开放协作的精神）。政策和治理工作和技术工作没有太大区别。针对这些工作，很多时候我们变得不那么开放，并不是出于必要的法律或隐私原因，而是因为这样感觉更容易；而这往往只是因为我们对这类工作不那么熟悉和自信。

尝试总结一下这篇文章的重点，关于开放协作的一些建议：

• 把社区当作合作伙伴，而不是客户；
• 需要不断迭代工作内容、沟通和反馈（和写程序一样，不断迭代，不要憋大招）；
• 及时从合适的人那里寻求反馈，特别是针对工作的目标和范围；
• 保持经常沟通，并且需通过多种方式进行沟通；
• 明确需要咨询和通知的范围；
• 保持团队的透明度：社区可以看到你们工作的整个过程，包括工作过程中产生的中间产物（可能是乱糟糟的）以及最后的完善的结果。
• 保持团队成员的透明度，每个团队成员的意见是公开透明的，并且他们是独立的个人，而不能仅仅当作一个团队进行沟通。

有些人不愿公开会议记录或文字记录，他们认为这样就无法畅所欲言了，或者他们不喜欢在网上分享自己的形象或声音。我认为这些都不能作为不公开的理由，公开会议记录或者文字记录，有助于后续问责和表明我们具有更高的透明度。你应该对自己的发言有信心，并且相信你的听众不会曲解你的话。作为一名领导者（如果你在做决策的会议上，那么你就是一名领导者），为了更好的结果和更好的工作过程，你要学会适应变化，适应不合理（你认为的不合理）。也许真的有些人可能会有安全隐患或会因为说话变得非常焦虑，但对于大部分人来说，不愿公开会议记录只是一种无用的安全措施。

文章转自 int64.me