In response to the specific question, I think “contentious review” happens sort of incidentally currently.
First of all, the Core Devs call is open to anyone to sign up and join the discussion to talk about an issue. It’s sort of the “public hearing” of Ethereum’s governance. If we get any active dissent in the call from someone who does not typically join, this is where we hear it out.
On the other hand, most people are quite busy and cannot attend these calls. The Core Devs (and this doesn’t really reflect any particular person’s job at the moment) summarizes the discussion in the forum threads and take it under consideration. If the dissent makes sense to them, they might discuss it during the call. Their own dissent may fall under this category too. It’s a very fuzzy process, but they try to account for things that affect implementation of the proposal, including non-technical things like “community sentiment”. If there are no known dissent that the participants, especially the client developers, deem to be a blocker to the implementation, a decision to move forward is made.
I think documenting how this system works by analyzing old calls and proposals would help document the process. We could draw clear parallels between this political process and other political processes across the world and look for opportunities for improvement and avoidance of capture.
For one, I think formalizing the Core Devs call as a sort of “public hearing” may help formalize things a bit. There are many parallels to a public hearing. There is a chairman of the discussion (@souptacular), there are the “lawmakers” (aka client devs and other interested parties), there are people who sign up to deliver public remarks. It gets recorded and documented for others to reference. I think there is a clear parallel.
Typically, in public hearings nothing gets “Decided”, it’s just everyone’s voice is heard. Perhaps what could be done is we could optimize for that, and then more contentious discussion of whether or not to implement to a different chat that gets deliberated with something like Chatham House rules so Core Devs feel more free to voice their concerns and the concerns of others without feeling targeted. This might improve things.
However, it is usually lawmakers that participate in these public hearings as the central figures. They are elected officials, whose time to hear out the discussion is paid for by the people they represent. We have a different system. The Core Devs call is made up of people from EF who have various capacities they speak to, client developers whose time is paid for by their respective employers and who obviously implement the discussion, and whomever signs up to discuss an issue. We’re not necessarily getting a representative sample of key stakeholder concerns, and we’re not getting detailed analysis from parties who may raise more legitimate issues with a proposal (such as security professionals and “crypto-economists” if I might use that term loosely). This is because people are too busy to attend the often 2hr+ call, and it would be volunteering so no one wants to do that either.
The wider governance is such that this harm is mitigated a little bit, although definitely not in an optimal way. In the end, full node operators specify what the network is by “voting” with their node whether or not to operate a particular software upgrade. Some nodes have more of a say than others. Mining pool operators, exchanges, and infrastructure operators all have a real legitimate say on the final state of the network, but at the expense of causing a contentious fork (which everyone wants to avoid). Adding a signaling mechanic for full nodes (e.g. an eth_vote(EIP) -> bool API endpoint) and random-sample querying nodes over a relevant period of time (1 month might be enough to make “voting” by sybil nodes overly costly) might be enough to gauge sentiment of what is the final layer of Ethereum’s governance.
Node “reputation” could be leveraged as well in help to filter these results. We might know which of these nodes are operated by those key parties mentioned above. We can use uptime and endpoint access metrics to determine the “sybil-ness” of nodes who choose to remain anonymous. Everyone in the community could vote in this way, and we help the ensure the security of the network as well in the process. This is just one concept, but every single proposal for how to deal with Ethereum’s governance requires a method of voting by “key stakeholders”, so we’ll have to do something like this eventually.
Who is willing to put time into figuring this out?
That is the toughest question. We are all busy and so far these type of analytics has been an unpaid and thankless job. Those with an interest in making core governance stronger should fund efforts to make it so, but these kind of wishy-washy statements from onlookers like myself are why nothing every happens.
I don’t know how to solve that.
