vlambda博客
学习文章列表

| 编辑：王皓月

| 设计：朱亿钦

| 翻译：徐红伟（stronghx）

| 审稿：Ted，一个影子

我们的开源团队分布在世界各地，有着不同的文化，而异步决策过程是我们团队的关键推动因素。在这篇文章中，我将解释它在 ASF 中起作用的原因所在。

2001年我通过 参与到 ASF 中，当时他在 Apache Fop 发起了关于我捐赠 jfor XLS-FO 到 RTF 转换器的讨论，这是我早些时候开发的软件。现在谈论 RTF 已经太晚了，它是一种糟糕的格式，嗯，我离题了。我目前是 ASF 董事会成员，一直在思考（和演说）关于 ASF 在协作和共享神经元方面所起的作用。

如果 ASF 项目中需要召开同步决策会议，即使是使用诸如 IRC 或视频会议的远程方式，我们的进度也会像蜗牛一样慢，因为在没有管理者也没有统一时间表的环境中，想找到一个所有相关人员都能参加的时间几乎是不可能的（大家分布在世界各地，时区不一样）。

正如 Paul Graham 所述[1]，当你按照生产者的时间表工作时，会议也会非常昂贵。频繁的会议将会破坏工匠的生产力，在我们这个行业（软件行业）中有很多的“工艺”，特别是当你正在构建前沿产品时。

那么，要想在不召开会议的情况下让大家异步地制定集体决策，需要哪些东西呢？

首先你需要一个中心化的异步沟通的通道。这个通道使用什么技术并不重要，但是它必须能够让每个人接收到相同的信息，并提供一种可用的线程式的讨论方式，可以为一个主题开辟分支，并忽略该通道中正在讨论的其它主题。这就像一个白板一样简单——如果人们经常访问同一个地方；或者像精心设计的网页论坛，可以通过任何移动设备访问，可以联系世界各地的人。在 ASF 我们使用普通的邮件列表，当人们按照正确的规则使用它们时，就会非常成功（参考下面的附录）。对这个通道进行存档非常有用，可以让新手了解事情是如何运作的，记录每个决定的原因，并且能够避免重复做同样的事情。

第二个必需的工具是建立共识，这样可以避免陷入僵局并确保决策往前推进。在决策中能够做到全体同意是最理想的情况，退而求其次就是达成共识，即在有决策权的人之间达成广泛的一致。在决策中要求全体同意或允许否决权会阻碍决策的进行，因此在 ASF 中否决权只适用于非常有限的决策类型，如我们的投票规则中所定义的[4]。在公司里面，决策权可以基于等级制度来打破僵局。这有时候不可避免，但是滥用它会导致你的员工失去他们的自主权和理想性，从长远来看，这会扼杀你的团队。

为了跟踪每一个决策，案例管理系统是最理想的工具。即使没有它您依然可以正常工作，这取决于您团队的规模和决策的数量。但是有了它就能够非常方便的讨论特定决策的细节并将相关的信息保存在同一个地方。您不需要非常复杂的软件，在 ASF 中我们使用相当简单的问题跟踪器。这是基于网页的系统，每个案例都在同一个页面中进行处理，而且留有评论和行动的历史记录。一些不紧急或非常困难的决策通常需要相当长的时间，所以将历史记录保存在同一个地方非常重要，可以避免重复的向团队新成员解释。在技术条件不允许的环境中，您可以用一张纸简要地记录每个决策的关键点，并把它保存在文件袋中。

使用案例管理系统所带来的一个好的附带作用是，每个决策都有唯一的标识符 ID，例如 FOO-123代表 FOO 项目的第123次标记。通过这些标识符，可以消除人们对所讨论问题的不确定性。

总而言之，以下几点应该可以让您的团队在无需开会的情况下进行异步决策，并记录下所有内容：

• 一个存档的异步通信通道，使得每个人都可以获得相同的信息，并可以进行线程式的讨论。

• 一种建立共识的方式，包括打破僵局的公平规则。

• 如果可能的话，用一个案例管理系统来跟踪每个决策的细节，这比异步通道中经常出现的一团糟的讨论方式要清晰得多。

董事会成员需要在会前阅读项目报告，一个简单的案例管理系统（下面会描述）有助于提前讨论问题，并确定哪些报告需要更深入的讨论。

假设大部分的董事会成员已经提前阅读了报告，并标记出哪些报告可以通过，哪些报告需要进一步讨论，我们在会议期间就不需要任何整理时间。每个人都能清楚的看到可能出现问题的讨论，因此他们有时间为此做准备，包括在会议前要求其他人作出澄清，这样我们可以毫不拖延的解决任何悬而未决的问题。

我们为此所使用的案例管理系统非常的简单，但它完全满足异步（或者半异步）决策过程的要求。我们的会议议程由源代码控制系统中的单个文本文件组成，其结构简单，为我们必须批准的每份报告和我们需要投票的每项决议提供了一个小型讨论空间。

议程文件的结构大致如下：

宣布开会

点名

干事报告

项目报告，标题和讨论空间

带有讨论空间的董事会决议

附录：完整的项目报告和其他辅助材料

项目报告的标题和讨论空间也非常简单，例如：

E. Apache Blazinator项目 [Bob Blazer / Bertrand]

见附件E

[Blazinator.

批准：bd, mm, dd, db, jc, ldv

评论：

bd：不确定为什么 LEGAL-123 会阻止他们的发布

ldv：他们正在等待提交者提供 iCAL 更新，因为之前收到的版本不完整。

bd：好的，谢谢，到时候再批准报告。

]

这个简单的结构化文本块为 Blazinator 报告的批准构建了一个非常简单的“案例管理系统”。

“批准” 行表示哪些董事会成员批准了报告，列在同一行中，以便简单的基于文本的工具可以验证和统计批准的人数。

“评论” 部分允许相关人员对报告发表评论（可在文本文件后面的附录中找到），并回复彼此的评论以期在会议之前达成结论。如果发生这种情况，批准此报告几乎不会占用会议中的时间，主席可以只需要列出此类预先批准的报告的项目名称（根据上述术语的“案例标识符”），询问是否有人反对批准它们。

结合 ASF 董事会的邮件列表，这为半异步决策过程构建了一个非常简单且非常高效的系统。大多数决策在会议之前就已做出，与会者可以将时间花在更有价值的地方，而不是在会议期间交换无聊的状态信息。

许多 ASF 和 其他开源的项目发布了改变世界的软件，但是却没有或很少召开会议，证明了这些技术是有效的。

如果您遇到效率低下或无用的会议，我建议您把这些原则应用到决策活动中有意义的部分。人们需要训练他们的技能才能适应这种高效的工作方式，而对于分布式的团队来说，回报是巨大的。

在 ASF，我们使用邮件列表来作为中心化的异步通信通道，这是建立在我们的“事情如果没有出现在邮件列表里，那么它就没有发生过”的原则上[2]。和最新的酷炫的工具相比，邮件列表看起来似乎过时了，但它依然是松散耦合的远程团队经常使用的交流方式，尤其是在需要精确引用的场合[3]和那些需要注意邮件主题的场合。不幸的是，我听说一些“现代”的邮件客户端在引用的处理上一团糟——离它们远点吧。

相关阅读 | Related Reading

开源飞控设备连接图介绍

人话版 GPL2.0 协议

暑期2020“大咖说开源”之吴晟 | 如何做一个开源玩家