夜天之书 #16 Open Discussion

今天要讲的是一篇旧文，起因是昨天文章发出后补充的评论里提到了这么一句

开源社区开头容易，人多了，思想碰撞了，“牧猫”的工作就难了。

这篇文章里对社区成熟度的衡量和发展有一定的讨论。此外，Public Design 和 Open Discussion 相呼应，以后一定还会再讲跟公开讨论相关的主题。

以下原文，有所改动。

TiDB Internals^[1] 论坛于四月底上线，目的是提供一个讨论任何有关 TiDB 相关项目的设计与实现的平台。在这篇文章里，我们将讨论为什么开源社区应该有一个论坛，以及这个论坛如今发展得怎么样了。

TiDB Internals 的 Internals 意思是内核或原理，借鉴自 Rust Internals 论坛，而不是内部或者秘密的意思。

如何衡量社区的成熟度？

我们可以通过社区成员，参与度，治理形式，以及影响力等维度来衡量社区的成熟度。这里介绍一个来自 ZoomQuiet^[2] 的社区成熟度模型。

•L0 无社区。大家不知道应该到哪儿讨论什么。•L1 有社区。大家知道到哪儿可以进行讨论。•L2 社区有规约。大家知道到哪儿应该讨论什么，否则有管理员出来纠正。•L3 社区可自治。大家知道社区目标以及管理规约，并明确成为组织者的条件和路径。•L4 社区自成长。社区变成大家日常生活习惯之一，并自学发掘或制造各种机会，关联各种资源，发展社区影响力。换句话说，社区归属感稳定。

大部分社区以 L4 形式启动，因为创始成员往往是一小群充满热情和信念的人，TiDB 也是如此。

TiDB 的创始人都是充满热情和信念的开源软件开发者，早期就加入社区的成员也是如此。

然而，随着社区的成长，一小群人的规模下通过 over communication 来同步的信息和项目目标，逐渐无法及时传递给新成员。核心成员被非开发事务缠身，行为守则和最佳实践成为部落知识，社区瞬间回到 L0 的状态。

这就是今年四月底的时候 TiDB 社区的状态。项目托管在 GitHub 上，但是整体表现是 open source code only 的。新成员不知道 TiDB 是如何开发的，因为 PR 突然地出现，蹦出来一群人 Review 和 Approve 以后，又匆匆地合并。一切都以新成员看不懂的形式在进行。社区当中没有持久化地保存成员讨论内容的渠道，因此新成员很难参与到社区中来。

实话说，GitHub issue 和 PR 从形式上是持久化地保存成员讨论内容的渠道，TiDB 维护了自己的 Slack 频道。然而，GitHub 上的评论很少被响应，Slack 只能保存近几个月的聊天记录。

我作为 TiDB 社区的一员，在看到这样的情况的时候，首先就是期望把社区带回 L1 的状态，也就是大家知道到哪儿可以进行讨论。所以我着手建立了 TiDB Internals 论坛。

应该选择哪一种渠道？

L1 和 L0 的不同点在于大家知道到哪儿可以进行讨论，前面我提到技术论坛解决了这个问题。不过实际上，论坛并不是唯一的解法。

在建立论坛之前，我在已经存在的邮件列表里发布了一个调查^[3]，题为“你认为什么是适合 TiDB 社区的讨论工具？”调查邮件把讨论工具分成了主题讨论和即时通信两类。

随后的讨论表明，即时通信可以暂不考虑，一方面是它的信息浓度太小，另一方面是开发者各有所爱，Slack 或者微信能够部分解决这个问题，但是都无法解决每一个人都知道到哪儿可以进行讨论的问题。因此，问题就变成了选择一个合适的公开进行主题讨论的渠道。

关于即时通讯工具的问题，有一些新的想法。TiKV 社区的 Xuanwo 正在实验一个桥接即时通信工具的方案^[4]，或许能够解决 Slack 不能保存所有信息的短处，以及各有所爱的问题。但是，信息浓度的问题是天然的，即时通信还是只能作为补充手段。

当时有这么几种可能的选项摆在我面前。

1.从我参与 ASF 项目的经验来看，邮件列表可以工作得很好。2.GitHub 的新功能 Discussion 看起来很酷，而且有好几个新潮项目已经开始用了。3.Apache TVM 和 Rust 等著名的开源项目有自己的技术论坛。4.GitHub issue 或者其他 issue 追踪工具也是不错的候选。

Issue

首先排除掉的选项是 issue 追踪工具。软件开发离不开 issue 追踪工具，但是它不适合开放式讨论。

Issue 总是绑定在某个代码仓库上的，并且通常围绕着一个确定且具体的主题。例如，报告一个缺陷或者记录一个具体的开发项。然而，开放式的技术讨论一开始往往非常模糊，不够具体。例如，粗略的功能设想，或者单纯展示一个小技巧。

Issue 的另一个不足是缺陷报告和各种开发项往往创建和更新频率非常高，这使得开放式的技术讨论经常被这些信息淹没。在处理具体问题时，开发者往往有模式可寻甚至机械式地处理，而在进行开放式讨论时更关键的是创造性的思维和联想能力。

这不是说我们不用 issue 追踪工具了，恰恰相反，TiDB 的开发绝不可能离开 issue 追踪工具。然而，它不是我们回答到哪儿可以进行开放式的技术讨论的答案。

邮件列表

回过头来看，邮件列表 和 GitHub Discussion 和论坛，都是很好的候选渠道。它们在发布一个主题和在专门的线程里进行主题化的讨论这一点上是一致的。只不过结果是论坛更适合 TiDB 社区的情况。

从我参与 ASF 项目的经验来看，邮件列表可以工作得很好。The Apache Way^[5] 强调了公开讨论的重要性，并要求所有交流都发生在邮件列表上。

TiDB 在当时已经有邮件列表了，而且我们甚至就是在邮件列表上做的调查，为什么不能就用邮件列表作为讨论的渠道呢？我把原因归结到文化差异和时过境迁上。

关于第一点，大部分 TiDB 的开发者并不成长于邮件列表在开源社区中扮演重要角色的年代。对于 Linux 和早期的 ASF 项目来说，邮件列表是最流行和有效的选择。相当多的 TiDB 开发者甚至不知道怎么订阅邮件列表，使用邮件列表进行讨论，等等。TiDB 的邮件列表在相当长的一段时间里并没有吸引到足够多的参与者，这也是我们无法把它简单的作为讨论工具的客观原因。不像 ASF 项目被规定要使用邮件列表，TiDB 的开发者有权选择自己的讨论工具，很显然，大部分人并不想用邮件列表。

关于第二点，不得不说人总是追逐新潮的东西。Rust 社区在 5 年前就停用了邮件列表，作为 ASF 项目的 Apache TVM 也将讨论的主战场迁移到了开发者论坛上，仅保留到邮件列表形式上的信息同步。必须承认，论坛对于下一代乃至当代的开发者来说，是一个更易于理解且更易用的讨论工具。

GitHub Discussion

GitHub Discussion^[6] 是 GitHub 为开源项目社区专门打造的协同交流论坛。

基本上，它跟一个论坛没什么两样。但是我们最终没有选择它，因为这个论坛必须绑定到一个代码仓库上。我当时说如果 TiDB 的项目组织形式跟 CockroachDB^[7] 相似，是一个中央大仓库的形式，那我们很有可能会采用 GitHub Discussion 作为无需运维的开箱即用方案。但很可惜，TiDB 社区不是这样的情况，它是由一系列代码仓库组成的。GitHub Discussion 绑定到一个仓库上无法适应 TiDB 社区的实际情况。

所以，我们选择论坛实际上是通过排除法选出来的。在下一节里，我会讲讲论坛如今发展到什么程度了，你可以从中看出这是不是一个合适的选择。

关于 GitHub Discussion 的问题，也有新的想法。源代码亲和确实是极大的一个优势。论坛讨论人数、议题和活跃度起来以后，社区有充足的议题和讨论意愿，可以将对应的项目的 Discussion 功能打开，就地发布 Release 公告，讨论技术设计等代码问题。关于这一点，还需要持续调研和观察 GitHub Discussion 的应用情况。

TiDB Internals 论坛发展成什么样了？

这篇文章最早写成的时候，距离论坛建立大概过去了一个月，有超过 70 个注册用户和 10 篇热烈讨论的主题。在前一个公众号发布的时候，已经有超过 160 个注册用户和近百篇主题发布。现在，论坛已经有超过 200 个注册用户，多篇有价值的技术讨论发表在论坛上。

当然，传统的运营指标并不是我们的目的，只是一个数字上的直观感受。我们的目标是建立起社区，让大家知道到哪儿可以进行讨论。甚至更进一步的，社区有规约。大家知道到哪儿应该讨论什么，否则有人出来纠正。

经过几个月发展，论坛已经有比较好的目录切分，几乎每天都会有新的主题出现或者现有主题的回复。

当初筹备的 TiDB Dev Guide^[8] 的提案，已经完成了前两个章节，并且在某些贡献者参与社区的过程中提供了可靠的内容支持。这里再次建议各位 TiDB 的贡献者或者任何关注开源社区的人，阅读一下 TiDB Dev Guide 目前已完成的 Contribute to TiDB^[9] 一章。你一定会有收获的。

论坛上提出的 Restructure Tests^[10] 提案，已经在逐步实现，吸引了不少于三十位贡献者参与。

论坛上提出的 Move parser back to pingcap/tidb^[11] 提案，当前正在讨论当中。

关于技术的讨论和问答比比皆是。一部分关键的开发活动，例如 TiDB 和 TiKV 的开发计划，以及社区决策，还有版本发布的信息也在论坛可以公开获取和讨论了。

如上所述，TiDB Internals 论坛已经吸引了相当数量的开发者的参与，并且从中诞生了若干个具体的开发项，例如 TiDB 测试框架的迁移，BR 和 Parser 并入 TiDB 仓库等等。具体的开发项仍然会落实到 GitHub 上完成，但是早期的开放式讨论会发生在论坛上。

TiDB Internals 论坛欢迎所有人讨论关于 TiDB 相关项目的设计和实现，开源协同的工作方式，以及有意思的点子等等。不过需要注意的是，论坛不是一个支持团队，关于 TiDB 使用一类的用户问题解答，社区有专门的用户论坛 AskTUG^[12] 来支持。

这里列举一些符合 TiDB Internals 论坛调性的主题，欢迎随时发起或加入讨论。

•重构一段代码，例如查询优化器的实现，但是不确定重构的影响和需要保持的兼容性范围。•有一个初步的想法，需要听一听社区开发者们的意见，例如支持 TiDB 计算节点并行承担单个查询。•关于架构设计或代码实现的疑问，想要请教模块专家。•分享参与 TiDB 开发者社区的经验或最佳实践，亦或是对 TiDB 开发者社区的期待。

避免私下讨论

这段内容节选自 Producing Open Source Software^[13] 一书，原文已经足够好，因此只做搬运，讲一讲整个 Open Discussion 的大背景。

即使你已经将项目公开，你和你的创始人也会经常希望通过私下讨论来解决困难的问题。这在项目的开始阶段尤其明显，因为此时需要做出许多重要的决定，而只有少量志愿者能够胜任。你会发现公开讨论的明显缺点：邮件对话本身的延迟性，需要保留足够的时间来达成一致，处理自以为是的幼稚的志愿者（每个项目都有；有些将来会成为明星贡献者，而有些会永远保持幼稚），也就是那些不能理解你为什么只希望解决问题X，而X明显是大问题Y的子集的人。秘密决定并使之成为既成事实，或者至少成为联合和有影响力的投票集团的坚实推荐，确实非常有吸引力。

不要这样做。

尽管公开讨论可能很笨重，但是从长远来看这样做更合适。私下里做出重要的决定就像是将贡献者排斥出项目一样。没有重要的志愿者会愿意呆在这样一个由秘密委员会做重要决定的环境里。此外，公开讨论也会从其副作用中获益，无论是多么短暂的技术问题，一经发起都会一直讨论下去：

•讨论有助于训练和教育新开发者。你不知道有多少双眼睛在关注着讨论；即使大多数人不会参与，仍然可能有很多人在静静的跟踪，收集软件的信息。•讨论会训练你如何向不熟悉软件的人们解释技术问题。这种技巧需要练习，你不能从已经知道你所知道的人那里获得这种练习。•之后，讨论和结论将会一直存放在公共归档中，可以保证以后的讨论不会回到同样的步骤中。见Chapter 6, 交流的the section called “归档的显著使用”。

最后，很有可能某个人会提出一个你从想到过的好主意，给对话带来真正的贡献。很难说这有多大的可能；这仅仅由代码的复杂程度和需求的专业程度决定。但是如果允许我使用轶事作为证据，我会证明这样做比直觉所期望的结果更好。在Subversion项目，我们（创始人）相信我们面对的是一组深入而复杂的问题，为此我们痛苦思考了几个月，我们很明确的怀疑在新建立的邮件列表中的会有任何人做出真正的贡献。所以我们选择了一条比较懒惰的方式，开始通过私下邮件讨论技术想法，直到项目的一个观察者嗅出了问题，并要求将讨论公开。眨了眨眼我们这样做了—后来的结果让我们十分惊讶，我们很快便获得了许多有见地的回复和建议。大多数情况下人们提供的想法都是我们从来没有想到的。结果是邮件列表中一下子多了许多非常英明的人；他们只是在等待正确的诱饵。可以肯定的是公开讨论比私下讨论会保持更长的时间，也能得到更多的产出，花费额外的时间是值得的。

我们不必把问题总结为：“团结就是力量”（我们已经见过许多更成功的团队），但可以确认的是有一些事情适于在团队中完成。首先是有了大量的审阅；其次是快速产生大量的想法。想法的质量由其所针对的思想决定，当然，在你用挑战性的问题刺激他们之前，你无法判断这些思考者是那种人。

当然，也有许多讨论必须在私下进行，通过此书我们会看到这种例子。但是我们有一个指导原则如果没有保持秘密的原因，那就公开进行。

要想使之发生，我们需要行动。仅仅保证自己所有的通告公开是不够的。你也需要劝说其他人放弃不必要的私下讨论。如果某个人尝试开始没有必要的私下讨论，你要义不容辞的立刻进行恰当的元讨论。在你将讨论成功的引入公开场所之前，不要对原始主题做出任何回复，或者去确定私下进行是否必须。如果你一贯如此，人们会很快会意，并开始首选公开论坛进行讨论。

References

[1] TiDB Internals: https://internals.tidb.io/
[2] ZoomQuiet: https://github.com/ZoomQuiet
[3] 调查: https://lists.tidb.io/g/contributors/topic/survey_what_is_a_good/82016508
[4] 桥接即时通信工具的方案: https://internals.tidb.io/t/topic/382
[5] The Apache Way: https://www.apache.org/theapacheway/index.html
[6] GitHub Discussion: https://docs.github.com/en/discussions
[7] CockroachDB: https://github.com/cockroachdb/cockroach/discussions
[8] TiDB Dev Guide: https://pingcap.github.io/tidb-dev-guide/
[9] Contribute to TiDB: https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/introduction.html
[10] Restructure Tests: https://github.com/pingcap/tidb/issues/26022
[11] Move parser back to pingcap/tidb: https://github.com/pingcap/tidb/pull/28015
[12] AskTUG: http://asktug.com/
[13] Producing Open Source Software: https://producingoss.com/