事情的起点，是 Go 仓库里一个很普通的 issue（golang/go#77273）。
在 Go 这种量级的开源项目里，每天都有人提出各种各样的提案：增加一个语法糖、调整一处行为、复活一个曾经被否决的设计……其中有相当一部分，是在重新提起一个早已被讨论过、并且已经下过结论的话题。
对维护者来说，这是一件很消耗精力的事。如果每个人都可以无限次地把一个已经决定的问题重新拉出来辩论一遍，那么决策永远不会真正「落地」，团队会被无穷无尽的回锅讨论拖垮。
于是，在这条 issue 的讨论里，有人贴出了 Go 官方提案流程（go.dev/s/proposal）中的一段话：
一般来说，对于「重新审议此前已经决定的提案」这件事，我们的做法遵循 John Ousterhout 在他那篇 Open Decision-Making 中给出的建议，尤其是其中「Reconsideration（重新审议）」那一节。
换句话说，连 Go 团队这样的顶级工程组织，在「怎么做决策、决策之后还要不要重新讨论」这件事上，引用的也不是某套高深的管理学理论，而是 John Ousterhout —— 也就是写《软件设计的哲学》那位斯坦福教授 —— 的一篇博客。
那一节的核心其实只有一句话：当有人想推翻一个已经做出的决定时，先问一句 「你掌握了什么新的信息？」（What new information do you have?）。如果没有新信息，那就不必重新讨论；如果有，那随时欢迎修正。
这套关于「决策」的方法论，远不止「要不要重新讨论」这一个点。Ousterhout 在这篇文章里，系统地讲了他在两家创业公司里摸索出来的一整套**开放式决策（Open Decision-Making）**框架。
下面是这篇文章的完整翻译。
开放式决策
作者：John Ousterhout，斯坦福大学计算机科学系教授
原文：Open Decision-Making
最后更新：2021 年 6 月 8 日
引子
在创办并领导两家创业公司的过程中，我亲历过形形色色的决策：有些成功，有些惨败。回过头看，那些好与坏的结果背后，其实有一套可以总结的规律。我逐渐形成了一套自己偏爱的决策方法，它处在「集权 — 开放」这条光谱中相当靠近「开放」的那一端：与其依赖少数几个人拍板，不如尽可能去汇聚许多人的集体智慧。
很多管理者对这种做法心存疑虑，担心它低效、担心自己失去掌控。但我的经验恰恰相反：
- 达成共识，往往比你想象的要容易。
- 领导者其实不需要把决策攥得那么紧。
- 尽早把争议摆到台面上，反而能减少后期的冲突。
