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–“RFC 7282: On Consensus and Humming in the IETF”–they ratified in 2014. The document cites a presentation given by Dave Clark in 1992, just as the web was gaining momentum. It is our hope that, by gathering these obscure historical moments and ideas, we can seed diverse cultures of love, internet style.

Rough Consensus and Running Code

Governing

Legibility

Chaos

How does this fit into Kernel?¶

Love is messy and unpredictable though, and often seems to be at odds with our very human desire for legibility. We want things to be at least roughly ordered and to "make sense". But this is not necessarily the way of the world. In fact, legible routines are often hallmarks of authoritarian structure, and so we need to find a middle way between the top-down imposition of one man's idea of order and the tyranny of structurelessness.

By combining insights from the two articles on which this brief is based, we hope to indicate how our own embodied being can give us the knowledge we need–as we need it–to navigate this particular set of complementary opposites constructively and, as 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 simplistic "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. In order to reach rough consensus, minority views must be addressed, with justification. Simply having a large majority of people agreeing to dismiss an objection is not enough; the group must have honestly considered the objection and fully addressed all technical issues.

In an article called “Rough Consensus and Maximal Interestingness”, Venkatesh Rao writes::

Using a familiar thinking pattern, the IETF addresses these challenges in the negative. They consider issues first rather than agreements; address them but don’t necessarily accommodate them; and understand (through iterative practice) that consensus is a tool and not a destination.

What follows is a condensation of the main points in the IETF’s RFC 7282:

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

1a. The two meanings of "compromise"¶

1. When it comes to engineering choices, compromises are expected and essential. We must weigh trade-offs and collectively choose the set of trade-offs that best meets the full set of requirements.
2. Among people, fcompromises are far less desirable. Such compromises occur most often when one group has given up and are 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-such reasons. You object to my proposal for this-and-that reason. 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. The final decision then 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 accommodating it, and concluded 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. We do, on occasion, take informal polls to get a sense of the direction of the discussion, but we try not to treat a poll as a vote that decides the issue. Sometimes, to reinforce the notion that we're not voting, instead of a show of hands, we "hum".
3. 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.
4. Another reason is to "take the temperature". A few loud hums for choice A and a larger number of non-committal hums for choice B might indicate that some believe there are serious problems with choice B, albeit the more popular by sheer number of people.
5. To re-emphasise the major point: a show of hands might leave the impression that the number of people matters in some formal way. It doesn’t.
6. 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 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 call 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 a minority has a valid technical objection, that objection must be dealt with before consensus can be declared.
2. It's the absence of an unaddressed open issue, not the number of people agreeing, which determines consensus. You may proceed in spite of issues that have been purposely dismissed, but not ones that have been ignored.

4b. Five people for and one hundred people against might be rough consensus¶

1. This is the most controversial scenario. 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.

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. 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 forward 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 some 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 can cultivate governance systems that determine what “valuable work” means and fund it simultaneously . Though it sounds great to "address all technical objections"–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. “Exceptions” in this context means only those proposals which do not adequately address valid technical concerns. There is the potential that certain proposals could be at odds with the culture and ethos of a given community, in which case lessons from political history–like defensive democracy–are fertile starting points for thinking about how to encode principles as a means of establishing credibly neutral incentive structures.

Legibility¶

We tend to reject illegible systems that we can’t easily understand and opt for more orderly approaches. The IETF brief was written in response to this tendency, which arises from the anxiety produced by ambiguity or “rough” systems that aren’t always exactly predictable. 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. Venkatesh Rao summarises the book in his own article called “A Big Little Idea Called Legibility”:

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:

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 can choose 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¶