Table of contents
- Illegible Consensus
- 1. Lack of disagreement is more important than agreement
- 2. Issues are addressed, not necessarily accommodated
- 3. Humming, not voting
- 4. Consensus is the path, not the destination
- Funded code running consensus
- Further References
Following on from last week's essay mixer, we'll both look back in history, and consult a popular online personality for a deeper introduction to internet-age institutions. In order to understand our roots, we turn to the Internet Engineering Task Force (IETF) and a governance document they ratified in 1992, just as the web was really getting going. In order to move through its most modern branches, we'll turn to Venkatesh Rao and James Scott.
How does this fit into Kernel?¶
The human desire for legibility is very real: we want things to be at least roughly ordered and to "make sense". But this is not necessarily the way of the world around us. Legible routines are hallmarks of authoritarian structure, yet we also need to find a middle way between the top-down imposition of one man's idea of order and the tyranny of structurelessness. This combination of articles presents such a way, wherein our own embodied being in a time and space can give us the knowledge we need as we need it to keep navigating the pattern of complementary opposites constructively, and always with humility.
"It is easier to comprehend the whole by walking among the trees and becoming a holographic, fractal part of the forest, than by hovering above it."
IETF governance revolves around the simple maxim that engineering is about trade-offs. As such, we need clear ways of thinking about how we make decisions. We ought to avoid "majority rule" and get to rough consensus decisions which promote the best technical outcomes.
Rough consensus is therefore a sort of "exception processing", meant to deal with cases where the person objecting still feels strongly that their objection is valid and must be accommodated. Balloting or looking at percentages cannot "determine" consensus in such cases.
Minority views must be addressed, with justification. Simply having a large majority of people agreeing to dismiss an objection is not enough to claim there is rough consensus; the group must have honestly considered the objection and addressed fully all technical issues.
In a different article, Venkatesh Rao discusses how:
"Rough consensus is about finding the most fertile directions in which to proceed rather than uncovering constraints. Constraints in software tend to be relatively few and obvious. Possibilities, however, tend to be intimidatingly vast. Resisting limiting visions, finding the most fertile direction, and allying with the right people become the primary challenges."
As with our own play of thinking patterns, the IETF addresses these challenges in the negative. They consider issues first rather than agreements; address them but don’t accommodate them; and understand (through iterative practice) that consensus is a tool and not a destination.
Prompt: Consensus is a tool, not a goal. We should use it for what three primary tasks?
Resisting limiting visions, finding the most fertile directions, allying with the right people.
1. Lack of disagreement is more important than agreement¶
- Coming to consensus is different from having consensus. In coming to consensus, the key is to separate those choices that are simply unappealing from those that are truly problematic.
- Closure is more likely to be achieved quickly by asking for objections rather than agreement.
1a. The two meanings of "compromise"¶
- Among engineering choices, compromises are expected and essential. We must weigh trade-offs and collectively choose the set that best meets the full set of requirements.
- Among people, far less so. Such compromises occur when one group has given up trying to appease the others. Conceding when there is an outstanding technical objection is not coming to consensus. Even worse is horse-trading: "I object to your proposal for such-and-so reasons. You object to my proposal for this-and-that reason. Neither of us agree. If you stop objecting to my proposal, I'll stop objecting to your proposal and we'll put them both in."
Prompt: When determining social consensus, should we ask for agreement or objections?
2. Issues are addressed, not necessarily accommodated¶
- "That's not my favorite solution, but I can live with it. We've made a reasonable choice" - this is consensus, not rough. It’s only rough when an unsatisfied person still has an open issue, but the group has truly answered the objection at a technical level.
- This relies on the good judgement of the consensus caller, or chair. Finding “rough consensus” means that not only has the working group taken the objection seriously, but that it has fully examined the ramifications of not making a change to accommodate it, and that the outcome does not constitute a failure to meet the technical requirements of the work.
- What can't happen is that the chair bases their decision solely on hearing a large number of voices saying, "The objection isn't valid." That would simply be to take a vote. A valid justification needs to be made.
Prompt: Does rough consensus mean everyone is satisfied?
No, only that all technical objections have been answered.
3. Humming, not voting¶
- We don't vote because we can't vote. The IETF is not a membership organization, it's nearly impossible to figure out who would get a vote for any given question. There are only “participants”, not “members”.
- One reason for humming is pragmatic: to find a starting place for the conversation. A hum can indicate that there were less objections to A than to B at the beginning of the discussion, so starting with the objections to A might shorten the discussion.
- Another is to "take the temperature". A smaller bunch of loud hums for choice A and a larger number of non-committal hums for choice B might indicate that some believe that there are serious problems with choice B, albeit the more popular by sheer number of people.
- There is deep symbolism here: a show of hands might leave the impression that the number of people matters in some formal way. It doesn’t.
- The formulation and order of questions asked can have huge effects on the outcome. Asking, "Who supports going forward with this proposal?", and asking it first, can cause more people to hum in the affirmative than would for differently formulated questions, or asking the same question after some more "negatively" framed questions. Any sort of polling must aim to prompt discussion and questions, not conclude the matter.
Prompt: Do the number of votes, hums, or hands matter in consensus-based decision making?
4. Consensus is the path, not the destination¶
- Consensus is a tool to ensure we get to the best technical outcomes.
- Experience has shown us that traditional voting leads to gaming of the system; "compromises" of the wrong sort; important minority views being ignored; and worse technical outcomes.
- Again, you cannot confirm that there is consensus by counting people, it must be about the outstanding issues and whether they have been addressed.
4a. One hundred people for and five people against might not be rough consensus¶
- If there is a minority who have a valid technical objection, that objection must be dealt with before consensus can be declared. This rules out vote stuffing.
- It's the existence of an unaddressed open issue, not the number of people, which determines consensus. As above, you can have rough consensus with issues that have been purposely dismissed, but not ones that have been ignored.
4b. Five people for and one hundred people against might still be rough consensus¶
- This is the most controversial result. It generally occurs in the case of small, active working groups where an objector recruits many otherwise silent participants to their cause.
- The principle is still the same: if the objection has been addressed, and the new voices are not giving informed responses to that point, it can still justifiably be called rough consensus.
- Sometimes, a show of hands can be useful; sometimes, it can be damaging and result in sub-optimal decisions. Sometimes, using a device like a "hum" can avoid those pitfalls; sometimes, it is just a poorly disguised vote. The objective nevertheless remains to protect against simple “majority rule” and get to the best technical outcomes.
Prompt: The existence of what key factor, rather than number of people, determines consensus or its lack?
An unaddressed open issue.
Funded code running consensus¶
Most of this is still relevant 30 years later, and there are two points which remain critical for any system of technical governance:
Voting ought to be about finding useful starting places for generative discussion, not reaching conclusions; and
Sheer number of people or votes does not determine consensus.
What is problematic now is that consensus is "called" by a chair, which is a position of authority we cannot afford if we are to build truly decentralized systems that function on a global stage. However, it's exactly the authority conferred by the formal position of "chair" which gives individuals the power to get work done once all technical objections have been addressed. So how are we to balance the lack of authority with our need to move foward along the most fertile paths?
The proposed solutions to this question generally take the form of some kind of distributed and dynamic reputation system, because reputation gives certain individuals the legitimacy required to shift conversations and social conventions. This is a necessary and salient point to acknowledge in the social protocols and culture which inform any system of technical governance. Where there are shadow hierarchies, there is abuse and inefficiency, and so individuals must be aware of the regard in which they are held within their chosen communities and respond accordingly. We state elsewhere that the idea for any kind of leader - read: host, or server - is to give away their importance without shirking responsibility.
However, we can perhaps turn to simple economics for other sustainable and resilient solutions. The old idea is "running code and rough consensus". However, the code we now all run establishes consensus, and makes money (literally). So, rather than having a single chair who specifies which path is best to follow for the whole working group, why not have as many working groups as we can currently fund by means of our shared code? We can even program non-linear funding mechanisms which also act as on-chain economic signals of support - as we saw with EIP-1559 - in order to determine collectively the best technical outcomes.
In 1992, there were sufficiently few people and resources online that it made sense we all came to at least rough consensus. Forking the internet in the 90's was not an option. However, if our votes are simultaneously economic actions that fund a given project, then we should not build governance systems that stand in the way of that project doing their work. It sounds great to "address all technical objections" but - in practice - there are often so many variables at play that doing so in a credibly neutral manner is impossible. Cost, however, is a single variable we can all reason about to at least a first approximation.
Rough consensus is just "exception processing" for people. When your running code already establishes economic consensus, you can leverage this to fund multiple different working groups with multiple approaches, removing the need to handle exceptions at the initial stage because you know it will be decided by actual use later on. This is not to say you don't need principles, just that you should think about ways by which you can encode those principles as economic incentives.
"In other words, true north in software is often the direction that combines ambiguity and evidence of fertility in the most alluring way: the direction of maximal interestingness."
Prompt: When running code already establishes economic consensus, do we need strong exception processing for people's technical objections such that we collectively explore only one option? Why?
No! Because votes are funds, so many different approaches can potentially be funded without addressing all technical objections in the preliminary stages.
We tend to reject "rough" systems and opt for more orderly approaches. It was precisely this tendency - arising from the anxiety produced by ambiguity - which prompted Pete Resnick to write the above article. And now, we're saying it's not even about rough consensus. It's about however many projects can garner sufficient support because, in open protocols for money, a "vote" is an economic signal which can simultaneously be used to fund what is being voted on.
If you're objecting to the inevitable chaos of such an approach, it's time to talk about legibility.
James Scott's book, Seeing Like A State, describes how modern states reorganized societies to make them more legible to the apparatus of governance. As Rao describes it:
"The state is not actually interested in the rich functional structure and complex behavior of the very organic entities that it governs. It merely views them as resources that must be organized in order to yield optimal returns. Importantly, this happens on both left and right: the failure mode is ideology-neutral: it arises from a flawed pattern of reasoning rather than values.
"This style of thinking leads to simplification, since a reality that serves many purposes presents itself as illegible to a vision informed by a singular purpose [...] The deep failure in thinking lies is the mistaken assumption that thriving, successful and functional realities must necessarily be legible."
Prompt: What kind of reasoning sees organic entities as resources to be organized in a legible way which yields uniformly high returns?
Don't misunderstand: there is - as always - a trade-off between "simple to understand" and "functionally useful", and there are some cases in which the first is genuinely useful. For instance:
"The bewilderingly illegible geography of time in the 18th century, while it served a lot of local purposes, would have made modern global infrastructure, from the railroads (the original driver for temporal discipline in the United States) to airlines and the Internet, impossible."
We can learn a great deal from the history of states and the very human desire for legibility. It does, in some instances, lead to improvement. For instance, we should learn from the IETF that:
Closure is more likely to be achieved quickly by asking for objections rather than agreement.
We should compromise between engineering choices, but not between people.
We must address issues and justify technical choices to the greatest extent possible.
Majority rule sucks.
We must use consensus as a tool, not an end.
We must build principled systems which cultivate our ability to make optimal collective choices.
That said, we no longer operate in a version of the internet where rough consensus about a single way forward is even possible, let alone desirable. We need to embrace the generative chaos and use economic code which establishes consensus to fund as many different approaches as is appropriate, without treating humans as exceptions to be handled.
"Reformers do not acknowledge (and often do not understand) that they are engineering a shift in optima and power, with benefits AND costs. Instead, the process is driven by a naive 'best for everybody' paternalism that genuinely intends to improve the lives of the people it affects."
Don't be a reformer. Build systems that help people govern themselves, and then - the most radical choice of all - let them actually do so.