Github 和 Stack Overflow 不是实现民主的工具 已翻译 100%

（标题也可以叫做：为什么我们应该为 Reasonwell 感到兴奋）

我喜欢 Github 和 Stack Overflow，但这仅限于代码领域。关于明主，我们需要另外的政策辩论工具。

有很多人感觉 Github 和 Stack Overflow 是我们现今明主社会正缺少的元素。

Git 和 Github 允许人们协作，同时又尊重每一个参与者的独立性。每个人都对自己的仓库拥有完整的控制权。每个人都可以 Fork 一个项目，公布，并且和其他任何人协作。任何人都可以提交补丁而不是依赖于经过授权的某些人。每个项目都保留了完整的历史记录（图表），使得项目更加透明和可控。Git 所拥有的去中心化结构使得这一切成为可能。

Stack Overflow 允许大量的人在一个结构化的问答中交流。和充满漫谈的论坛讨论不同的是，它鼓励将最有效的信息置顶。用户可以通过贡献优质信息给 Stack Exchange 网站的主题中积累声誉。

我们认为协作开发软件过程中使用的工具的民主性是很有价值的 —— 那么我们为什么不能把它们纳入我们的政策辩论中呢？

我们可以这么做。

我们可以吸取巩固 Git, Github 和 Stack Overflow 的核心思想，用它们去打造一个全新的特别设计的结构化的辩论工具。这个新工具就是 Reasonwell。

软件和政策的关键区别是，软件项目的单位是源代码文件的分级存储，而政策推理的单位是论点图。它们是十分不同的。

论点图有断言和争论组成。断言是陈述一个命题的句子。争论是一组断言（前提）一起证明或者反对另外一个断言（论点）。这些前提断言也可以由其他的争论来证明或者反对，结果通常形成一个树形结构（更准确的说法是有向图）树的每个分支是成串的任意长度的推理。这个图可以有环，例如当两个断言互相争论： “我们应该征收碳排放税” vs “我们不应该征收碳排放税”

为了充分理解论点图如何工作，我推荐你看 Austhink’s 的教程 和 这个blog.

一个项目的源码段之间的依赖关系是隐式的、依赖语言的和复杂的。我们需要将整个项目代码作为一个连贯的单元来维护，每个快照作为一个提交被包含。我们有各式各样的测试工具来验证一个提交确实是一个连贯的代码段。一个提交最终会被部署，并且我们会用版本控制来管理增量变化趋势。

而一个论点图的依赖是显式并且非常简单的。如果你相信一个论据的所有前提为真，那它是唯一有效的。一个矛盾的陈述将依赖于一个其中包含一个假前提的论据。

这里我并不是说法例之内和之间的依赖关系是简单的--远非如此。但我也不提议我们的政策讨论应该专注于立法文件的共同发展，而是应该关注围绕论点图上的断言进行推理。

在一次辩论中，你的观点不需要打包又打上版本号然后一次性提交。为了理解你对辩论的增量式的贡献，我无需检查每一个补丁，那些补丁代表了分布于一次辩论中，基于一个任意数量断言的，你的观点变化的汇聚集。我只需要考虑你提出的支持或反对某个断言的论点，而我又对该断言持有观点，然后决定是否我要接受你的论点。当我认为你的论点中的前提是事实真理，我就可以考虑任何人基于那些前提的论点，而不仅仅是你的。

你拥有你的观点，但是（除了消息出处）没有人拥有断言或论点。你的观点可以随着时间而变化——它们是可变的。而断言与论点可以被认为是不可变的对象。

希望这是为你介绍论点图模型的开始。现在详细分析一下Reasonwell对象模型的核心：

一个断言是一个不可变的字符串，由其SHA256哈希码鉴定。

一个论点是一个不可变的记录，由其SHA256哈希码鉴定。它包括：

• 它关系到的断言的鉴别码（争论点）
• 一个布尔值标识它在辩论中支持或反对这个论点
• 构成这个论点前提的一个或多个断言的鉴别码集

一个观点是一个可变的记录，关系到某个用户对一个特定的不可变的对象的积极或消极的情绪。一个基于断言的观点显示了该用户认为该断言为真还是为假。一个基于论点的观点显示了用户是否希望该论点出现在它们的论点图之中。如果在他们的推理中它是其中因素，他们会接受该论点；如果不是他们会拒绝它。接受一个论点不能决定一个人对争论点的观点——由于支持或反对一个断言而接受论点都是有效的。

正是在这里Stack Overflow部分出现了：当你访问某个断言的页面，你看到一个支持的论点列表，和一个反对的论点的列表。接受一个论点让它在列表中票选提高，反对它使它票选降低。Reasonwell的主要目的是搜集关于断言的近距离的最佳论点。如果有的论点已经获得公认，你可以采纳它，或提出改善它的修改，而不是添加多余的论点到总的内容容器中。

Reasonwell的对象模型覆盖了一些不可变对象的演进类型，以捕捉一次辩论中的论述的其他方面。一个假定(assumption)代表了一个概念，即一个论点是无效的，因为它基于一个可能错误的未声明的前提。一个瑕疵（flaw）代表了一个概念，即一个论点是无效的，因为某些方面它是逻辑矛盾的。一个修改（edit）代表了一些断言或论点最好是另一些的建议。这些对象都同样由SHA256哈希码方案鉴定，像断言与论点一样，而且用户可以对它们之中任何一个拥有可变的布尔值观点。

Reasonwell参考并扩展了Git的模型支撑对原文的引用和作为断言回应的问题和争论，非常类似于Stack Overflow。当发现一个观点在特定场景下才有效时Reasonwell中允许扩展这个观点的表述，而不是陷入陷入无休止的对与错的争论。

再来说说Github的部分：Reasonwell为每一个断言提供全局视图，用来展示来自正反两方面用户的争论的聚集。Reasonwell还会在个人页面展示你自己的观点，地址reasonwell.com/username/... 。别人浏览你关于某个断言的观点时，除了能知道你是同意或反对，他们还能知道你认同或者反对的争论。当他们查看你关于某个争论的观点时，他们能获知你认同还是反对和为什么反对。这些页面看起来像选举指导卡片（how-to-vote cards），高亮标记出了代表支持你观点的选择框。你可以添加唯一的URL，在那儿所有人可以看到你的观点和推理、采纳你的观点或者提出新的争论或校订(edits)。

在Reasonwell中，我们没有必要去发出请求归并请求。当你提出了一个论点，这个论点就会展现在所有支持或反对这个断言的用户面前。当你向一个已有的论点提交修改意见后，它就会展现在所有支持该论点的人的面前。当你基于一个不正确的假设之上，提出一个论点，它就会展现在所有同意该论点的人面前。如此往复。大众会给建议评分或者忽略掉，就像Stack Overflow上面提交的答案一样。

Reasonwell的信箱会提示那些你还没有提出你的个人意见的论点，论点修改，缺陷和假设。它还突出跟你的论点地图不一样的信息，例如你对某些陈述表示反对的其他人的同意论点；还有你对某些论点提出反对，但未指出反对的原因。通过发表你的意见来参与讨论，接受或者拒绝新的论点或者编辑已有的论点，对你同意的论点提出点评，等等，直到你的信箱变成空为止。在新的邮件提醒到来后，讨论又再继续。

像Git，Github和Stack Overflow一样，Reasonwell的文本分析不依赖复杂的启发式或算法。游戏的规则直接易懂。辩论的参与者不觉得他们会被系统的一个不透明的执行者之于不公正地劣势地位。

围绕一个协作论点图构建辩论使你能够在一个有很多参与者的辩论中持有自己的观点。在辩论中的每个论点被聚合成一个组织结构，每个组织结构的信息容量由不同想法的数量，而不是由参与者的数量决定。这就像与一个人辩论一样--一个人提出观点并说服其他不赞同这些观点的人。

Reasonwell以一种像在Github上兼容而灵活的协作软件开发、像在Stack Overflow上结构化和过滤的问答交流一样的方式促进协作辩论。