Open Decision-Making Is Incomplete
New information isn’t the only reason to reconsider decisions
The Go programming language project uses a public proposal process to evaluate changes to the language, libraries, and tools. Its guidelines for reconsidering earlier decisions explicitly refer to Open Decision-Making (ODM), a framework described by John Ousterhout. ODM encourages broad input and consensus, but says decisions should be reconsidered only when there is significant new information.
I’ve seen Go team members invoke this rule when a proposal seeks to reverse a previous decision. I think the rule is incomplete: a group can have good reasons to reconsider even when the underlying information hasn’t changed.
Ousterhout explains the rule:
On the other hand, you should not reconsider a decision unless significant new information has come to light since the original decision was made. If no new information is available, then reconsidering a decision will probably produce the same outcome as the original decision, wasting everyone’s time. It’s not unusual for employees to come to me weeks after a decision was made: “John, I voted against the decision to XYZ, and the more I think about it the more convinced I am that it was wrong; I really think we need to reconsider this.” My answer is “What new information do you have?” If the answer is “none”, we don’t reconsider. In situations like this it helps to have a record of the arguments presented during the discussion, so you can verify that new information really is new. If you make it too easy to reopen decisions you end up vacillating back and forth where no decision is ever final and employees hesitate to implement decisions because they don’t believe they are permanent.
In short: Don’t reconsider decisions if there’s no significant new information.
However, in a consensus-based process such as ODM, decisions aren’t based on information alone; they’re based on consensus, which is based on opinions, which are based on information. It’s possible for opinions to change without new information. If enough opinions change, then so does the consensus. If the consensus changes, then the decision should be reconsidered. If one person comes to you, as in the quotation above, with no new information, that’s one thing; but if half the group comes to you individually or all together with no new information, that’s something else. There’s no new information, but an important input to the decision-making process has changed and shouldn’t be ignored.
It also doesn’t take into account that opinions aren’t determined by information; they’re determined by perspectives on information, and those perspectives can change without new information. That doesn’t mean that simply changing one’s mind is necessarily a good reason to reconsider a decision: a person can change their mind arbitrarily, without any substantive change in their reasoning. However, people can also develop a genuinely different perspective on the same information, and that can be a legitimate basis for changing an opinion. Anyone who’s ever slept on an important decision before making it understands this. Why do people do that if there isn’t new information? Because time sometimes yields fresh, valuable perspectives. So can going for a walk, doing something creative, or washing the dishes. Sometimes the change in perspective happens after the decision is made. That’s unfortunate, but at least for reversible decisions, the possibility should be taken into account by the decision-making process.
Two Go proposals illustrate the distinction between new information and a new assessment of existing information:
- Reverting the default language version for new modules (#77653): I filed this proposal after
go mod init, the command that creates a Go module, began selecting the previous Go release’s language version rather than the installed toolchain’s version. Ian Lance Taylor initially objected that there was no new information to justify reconsideration. The proposal was nevertheless accepted. One commenter argued that the release provided the first opportunity to receive experience reports; I see the central dispute as a reassessment of the same trade-offs, especially who the default should serve and how much weight to give the inconvenience of an extra setup step. The discussion was worth having even if those trade-offs were already known. - Adding generic methods (#77273): Go’s original generics design omitted methods that declare their own type parameters. The design primarily viewed methods as a means of implementing interfaces, and generic interface methods presented substantial implementation problems. It considered allowing generic methods without letting them implement interfaces, but questioned the value of methods in that case. The later proposal by Robert Griesemer explicitly describes a change of view: methods are also useful for organizing functions under a type’s namespace, independently of interfaces. That possibility wasn’t new—the original design had considered it—but its value was understood and weighed differently.
One could characterize these changes in perspective as “new information” to argue that these cases are consistent with ODM, but that stretches the meaning of “new information” beyond the point of usefulness. If a change in the group’s assessment of existing information can always be characterized as “new information,” then “new information” isn’t really a meaningful criterion for deciding whether a decision should be reconsidered. Worse, it can be used to bias outcomes: whether something counts as “new information” becomes a matter of how someone chooses to characterize the change in opinion.
So is ODM bad? No, it’s just incomplete. A substantial change in any part of the decision-making process, from information to individual opinion to group consensus, should be sufficient grounds to revisit a decision. The parts that inform individual opinion can include perspective, interpretation, analysis, and judgment. The trick is determining whether a substantial change has happened. Importantly, reconsideration and reversal are different things. A changed opinion shouldn’t automatically reverse a decision; it should create an opportunity to determine whether the consensus has actually changed.
What would that look like in Go’s proposal process? If a proposal intends to reverse a decision due to a change in opinion, it should be allowed to collect comments and votes for a reasonable period to determine whether the consensus has actually changed. If the discussion does not reveal a clear change in consensus, then close it. If it does, the decision can be reconsidered on its merits. This preserves the useful part of ODM—preventing decisions from being endlessly reopened based on one person’s unchanged arguments—without making “new information” a prerequisite for reconsideration. The discussion of #77653 shows why this matters: reconsideration allowed the project to reassess its default and accept a reversal. A proposal author should be able to argue that the reasoning or consensus has changed without having to redefine that change as new information.