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.

Rough Consensus and Running Code

Governing

Legibility

Chaos

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.

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:

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.

1. Lack of disagreement is more important than agreement¶

1. 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.
2. Closure is more likely to be achieved quickly by asking for objections rather than agreement.

1a. The two meanings of "compromise"¶

1. 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.
2. 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."

2. Issues are addressed, not necessarily accommodated¶

1. "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.
2. 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.
3. 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.

3. Humming, not voting¶

1. 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”.
2. 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.
3. 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.
4. 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.
5. 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.

4. Consensus is the path, not the destination¶

1. Consensus is a tool to ensure we get to the best technical outcomes.
2. 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.
3. 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¶

1. 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.
2. 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¶

1. 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.
2. 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.
3. 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.

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:

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.

Legibility¶

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:

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:

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:

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.

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.

Further References¶