非正文：在 Twitter 上看到 Nick 分享的关于开放协作的文章，就想到自己之前参与的一些开源项目协作时候踩的坑，就忍不住的认真读了下去，发现这是一个不可多得的好文章，尝试翻译下来（感谢 ChatGPT），希望可以帮助更多的国人更好的参与开源项目。 原文：Some thoughts on open collaboration
Rust 是一个开源项目，不仅仅是开放源代码，更意味着该项目的工作是公开、包容的，并需要和更加广泛的社区相互协作。但是，有时候这样的工作是非常困难的，尤其是那些会激起许多人强烈反应或超过大多数人的工作经验的工作，表现的更加明显。制定策略和治理规范就是这样的两种情况，尤其需要公开的推进这样的工作是非常非常困难的！特别是主要具有技术背景的人从事这样的工作的时候更加困难。我自己就试过很多次这样的工作，结果都不是很好。
最近，我觉得目前 Rust 项目在制定项目治理规范和商标的策略的工作没有达到预期的开放协作的标准。自己亲身参与这些工作的同时，也在试图找出为什么会出现这样的情况的原因，但结果不尽人意，尤其自己在过程中，有时候也没达到自己对友好和同理心的要求。因此，我尝试换一个角度，写下我理解中推进这些工作的正确步骤，以及如何确保成功推进这样工作的想法。很多时候，说起来容易，但是做起真的很难，即使我们知道行动的目标和步骤，实践起来也是很难的。我希望这篇文章能够对此有所帮助。虽然我在尝试做这些事情时失败的次数比成功的次数还要多，但希望你们可以从我的错误中学到经验，吸取教训。
在开始之前就做正确的事情也是很难的！尽管以公开的方式制定策略规范，比起私下推进需要投入的更多，需要更多的努力，但是你必须这么做！如果不公开地去制定策略，就没办法达到想要的结果，同时还会激起人们的情绪，会让整个社区变得糟糕。保持公开是这个工作的必要部分，虽然会导致工作花费更长的时间，也需要在工作上投入更多的感情。但是从长远来看，保持公开是最好的选择。这就像是写程序需要写测试、写文档，早上需要刷牙一样，你必须这样做。
此外，这件事情没有什么捷径。如果你只是私下分享你的工作结果，那么你是错的。你必须主动进行沟通，并确保你的沟通是良好的。除了主动沟通，你还需要进行协作。
我经常看到许多人将这个工作流程严格定义为两类：一种是绝对公开的，例如将所有工作内容都在一个公开的仓库中公开，希望将整个世界的所有人都参与进来；另一种是秘密的工作，只偶尔发布一些工作结果以及一些调查问卷。使用第一种流程无法推进大规模工作，会导致整个过程十分混乱并产生不可预测的结果。因此，在实际工作中，我们应该避免这种情况。同时，第二种工作流程也是不可取的，因为整个流程不符合开放工作的精神。这样的流程就像一些项目，私下写代码，写完后直接公布结果，然后美其名曰“开源”。整个过程社区没有参与，没有贡献。
我认为正确的方式是在适当的私有范围内进行工作，每个工作阶段都有意识地让特定范围的社区人员参与其中。
首先，我将介绍一些有用的概念，以及我认为必须遵守的原则。
为什么没问过我？
Paul Ford 将这个问题称为“网络的根本问题”。Aaron Turon（这个链接的演讲非常好，建议观看）在 Rust 中推广了这个问题作为一种思考社区协作的方式。我也认为这是推进这类工作的一个非常重要的视角。
人们希望被赋予权力，并希望他们能够参与其中。这是因为人们不想被忽略，不想总是思考“为什么没有问过我”的问题。
这个口号背后的理念催生了 RFC 流程及其早期的演变，并催生了 Rust 项目的开放开发的方式。真实的情况是并不是每个人都有平等的投票权，而是每个人都觉得自己真正地参与进来，得到了尊重。
RACI是 Responsible（执行人）, Accountable（责任人）, Consulted（需要咨询的人）, Informed（需要通知的人）”的首字母缩写。这个是一个用来识别哪些人应该参与进来的思考框架。就像许多其他概念一样，这个概念可能会被过度强调而导致整个流程变得死板或者是令人不舒服，但是如果我们能够理性的使用，这个概念将会挥发很大的作用。这里我对这个概念的理解和描述可能会和一些在学院里老师讲的有些区别。这个概念还有一些其他的解释，如果有兴趣可以自行搜索查阅。
按照 RACI 框架可以将人分成一下四类：