技术讨论中的结构缺失

人类是令人惊叹的生物。在讨论一个复杂的问题时，他们能够在头脑中保持多个独立的论点，即支持和反驳证据的片段，并能够将这个系统崩溃为具体的解决方案。我们可以花几个小时浏览Github上的问题评论，重建观点，理解讨论的意义。问题是：我们实际上不想使用这种能力，也不想经常浪费时间。

你听说过“铁锈中的异步者”吗？有没有想过为什么核心团队选择了一种全新的语法来实现这一特性？让我们潜入水中，一探究竟吧！这里是#57640，有512条评论，请大家在表达自己的观点之前检查一下#50547(只有308条评论)。接下来的讨论一定让人精疲力尽。我不知道没有摘要注释怎么可能导航到它。

另一个例子是WebGPU中的循环语法。569期只有70条评论，中间多次尝试总结讨论。可能至少需要几个小时才能从外部为某人获得群体推理的要点。这还不包括通话记录。

GitHub有表情符号，允许某些评论表示更多支持。不幸的是，我们的本性是，当我们同意意见时，就会受到欢迎，而不是当它们以建设性的方式推进讨论时。他们到处都是，也帮不上什么忙。

不过，让讨论有一个非线性结构会有所帮助。树！它们让关注HN和Reddit线程变得容易得多，但它们也有问题。有时，一个真正重要的评论被深埋在其中一个分支中。另外，当人与人之间有一些来回争执时，树不能很好地进行对话。

这就引出了我们的观点：大多数技术讨论都很糟糕。并不是说人们不能提出好的观点和进步，而是讨论没有结构，太难跟上了。我在现实中看到的是极少数专心致志的人的大量关注，以及其他人对专注的人的委托。许多观点被歪曲了，许多观点从未听说过，因为评论流很快就过滤掉了大多数潜在的参与者。

我寻找解决方案的第一站是讨论。它被许多社区成功使用，包括铁锈用户。不幸的是，它仍然是线性结构，并没有给Github带来很多东西。例如，试着关注一下2020年关于生锈的讨论。

然后我研究了专门为结构化论证设计的平台。今天最受欢迎的是Kialo。我还没有对它做过很好的评估，但似乎Kialo并不是针对工程师的，它是一个我们必须注册才能使用的平台。希望通过这样的系统使用Markdown，我偶然发现了Argdown，并意识到它结束了我的搜索。

Argdown引入了定义文本中参数结构的语法。陈述、论点、命题、结论--它们应有尽有，只需在您的文本编辑器中(特别是如果它的VSCode有一个插件)或操场上编写即可。它有命令行工具可以从.argdown文件生成各种衍生工具，如点图、Web组件、JSON等等。当然，也支持使用Markdown进行格式化。

这一发现给我带来了两个问题。(1)-在这样的系统中，现有的辩论会是什么样子？以及(2)-我们如何才能将工作流程转向使用一个？

因此，我选择了WebGPU讨论中最具争议性的话题，并试图重建它。主题是关于选择着色语言，以及为什么SPIR-V不被接受。W3C小组在两年多的时间里对此进行了讨论，很明显，以Google的Tint提案为起点，做出采用WGSL的决定存在一些误解。

我试图在https://github.com/kvark/webgpu-debate，中重建辩论，用论证图的第一个版本来构建SPIR-V.argdown，解决问题(1)。存储库接受由CI检查语法正确性的拉请求，邀请每个人进行协作，解决(2)。此外，工件会自动上传到Github-Pages，以一种易于探索的方式呈现讨论。

我很高兴能有这种新的方式来保存和发展技术辩论的结构。我们可以继续使用代码托管平台，争论问题和公关，同时巩固这些.argdown文件中的核心点。我希望看到它更广泛地应用于技术工作组的工作流程。