I see it more as a signaling process. “This is the time we’ve set aside to discuss all the possible issues with the proposal”. The point is to gather the feedback to consider it all together, and not to fan the flames of argument. Everyone gets a chance to say their piece, the time to respond to each criticism is after that call.
We sort of have this now in the EIP GitHub and “discussions to” FEM, but that is more written testimony whereas this would be really public. I think it should be the author’s responsibility to respond to all criticisms before it is allowed to move forward to Core Devs
A simple suggestion I’ve made on ethereum/governance is just to add a post-meeting statement of what consensus was reached on the issues discussed to https://github.com/ethereum/pm. That might have helped prevent a lot of confusion in the progPoW case, where @souptacular’s statement of the consensus was buried in the middle of a badly transcribed discussion.
The Ethereum Core Developers develop and manage a technical platform and service. Like all service providers we must remain reasonably neutral among the users of our service, and thus relatively narrow in the considerations that are relevant to our deliberations. Where an issue cannot be presented in technical terms, even as broadly stated as “the health of the network,” I think the Core Devs are simply not equipped to make a decision.
The review that matters to the Core Devs is finalized as a consensus in the AllCoreDevs call. Reaching consensus on contentious issues is difficult enough. Contention that occurs after consensus in is reached is nearly impossible to deal with. So it seems essential to reduce contention by participate in the process before proposals get to the core devs, including the discussion and Last Call process.
One way to participate–and perhaps the best way to present issues to the Core Devs in a form we can take action on–is to prepare an Ethereum Improvement Proposal. That forces the proposer to present arguments in more technical terms, even as broadly stated as “the health of the network.”
I don’t believe most people have strong complaint with the current process when it comes to purely technical issues. The problems are related to non-technical disagreements. Block reward reduction, recovery proposals, proof of work algorithms, etc. all were not technical challenges (or if they were those were handled by the proponents), but it is ultimately on the Core Developers to decide what they code and what they don’t.
Unfortunately, it isn’t as simple as “bring a quality EIP to the Core Dev meeting and if no one has technical objections then the Core Devs implement it”.
Yes, the more “purely” technical the issue it the easier it is for everybody. I’m just suggesting that more participation before difficult decisions would be more helpful than complaining after difficult decisions, and that filing an EIP is one of the most powerful forms of participation.
Take the ERP EIP. People spent a lot of time and energy crafting that EIP and ensuring it was technically sound. Then when it got pushed up to the core devs, no clear decision was made and no clear process was followed for making a decision on it.
This is what EIP authors have to look forward to right now, a lot of hard work followed by an undefined process for decision making and no clear decision as the outcome. This is certainly not incentive compatible with encouraging people to write good EIPs, it instead incentivizes people to first try to radicalize the community or have backdoor conversations with core devs to get a feel for how the undefined process will go prior to putting in the effort.
With a well defined process for deciding what goes into clients, EIP authors have a chance at being able to predict the outcome before they sink a ton of time into the project. If their prediction is that it will go through, then they can dedicate the effort to do all of the work.
I agree that the process needs to keep improving, and am open to suggestions on how to improve it. I don’t see how any process for evaluating proposals could give you certainty up front, but we can clearly do a better job of managing the process.
Right now I’m just trying to get clear on what the current process is, such as it is, and suggest how best to work with it.
We all need to accept and resign ourselves to the fact that, for now, Ethereum is and, for the foreseeable future, will remain a technocracy. One reason is that, while not all decisions are purely technical, nearly all important decisions have at least a substantial technical component. Another is that, while most of us, myself included, would prefer something more closely resembling a democracy, that is simply not possible unless and until we have a more formalized conception of identity, which we’re nowhere near close to.
The core devs should establish a steering committee. This would be off-chain but a little more formalized than core devs and would have a mandate of deciding on these more contentious questions. I envision seven or nine people who are trusted, who have a strong technical understanding of the protocol, representing most or all of the largest groups of stakeholders, and including experts in relevant areas such as economics, philosophy, governance/political philosophy, ethics, law, etc. (or with the resources and mandate to call in experts as necessary). Yes, it may be hard to assemble such a group but I believe it’s possible. They should rotate often, every year or so. And it should be an “opt in” process whereby the core devs refer individual issues that they don’t want to decide on.
There are 1000 ways you could poke holes in these ideas and I encourage you to do so, but please be constructive and offer alternative ideas. No, this won’t please everyone but I believe it’s a workable proposal.
@lrettig I think it is valuable to acknowledge reality, and I agree that technocracy is how things currently function (sort of, see below).
However, the Core Developers have asserted that they do not want to make hard decisions, so what we currently have is a technocracy where the leaders don’t want to lead, which is actually worse than having a technocracy because it means no one is steering the boat.
I think that either the core developers need to accept the power they have, or we need to find someone to fill that void. Whether that is Cat Herders, or Magicians, or @AlexeyAkhunov or someone else or some other group I think matters less than it matters having that void filled by someone.
At least, they don’t want to make decisions that are anything other than technical. And at this point, are probably a bit skittish about technical decisions that may be perceived to have non technical elements.
Nothing goes into the client software that the core developers don’t put there, and nobody can make them put it there. That is the power the core devs have. What is the void you want to fill, and how would it change that situation?
The core developers have expressed that they do not want to make any contentious decision. As you say, they ultimately write the code, so what ends up happening is when they are presented with a decision that they feel is “contentious”, there is an incredible amount of weight in favor of the “do nothing” option.
I dislike decisions being made by way of the person/group who is in the position to make the decision simply ignoring the issue because they don’t want to offend someone, rather than because they believe that not acting is the right thing to do.
It is akin to having a leader who is in a coma. Sure, they are making decisions in the sense that they are “deciding to not change anything”, but that isn’t a good leader.
What I would like to see is a person or group who is willing to make decisions even when they are contentious. Someone or some group who will stand up and say, “we have heard the arguments from all sides and we are going to do (or not do) X”. This person or group needs to be respected enough by the core developers such that when a decision is made, the core developers will strongly prefer following it over “do nothing” (of course, they still retain veto power).
My personal problem with being a decision maker in a contentious process is that I am a software developer, not a politician. And the difference is that politicians enjoy many more legal privileges that protect them, for example: https://en.wikipedia.org/wiki/Parliamentary_immunity
And this is exactly why certain pressure strategies can be used to easily remove dissenting voices from such public, yet legally unprotected decision bodies
EDIT:
To add to that, the only way to make an efficient governance system that can cope with contentious decisions, but operates in an extralegal space, is to use so-called the “veil of decentralisation”. And that means always put contentious decisions to the hands of the users of the networks, or the operators, who are not easy to identify and pressure
Which is not at all an easy thing to do, and is itself contentious.
What I keep calling for is more self-organization of communities of users and operators, and more discussion within and across communities. I think the Magicians have shown how that can work. That could reduce the amount of contention in the first place, and focus remaining contention into arguments that the Core Devs can actually deliberate.
But in the end the Core Devs have to decide what software goes into the next fork, and the community takes a huge risk not to follow. I don’t know that we can avoid that responsibility.
I agree pretty strongly with this. We need workable governance. I made a proposal for one way to do that here:
@AlexeyAkhunov raises a very valid point that anyone in the decision maker’s seat is potentially opening themselves up to legal liability. So I think we also need to work closely with legal counsel to make sure we have institutional structures in place to protect the decision makers.
I’m not sure I agree with this, and in any case, we should get some legal opinions here. In my opinion it’s less about decentralization (which was more of an issue with the SEC weighing on whether ETH was a security) and more about making sure we have the right legal structures and protections.
We have at least two resources we can turn to in order to figure this out. One is EF, the other is COALA. I’ll begin a dialog on this question with both. Frankly I’m not sure the Magicians is the right forum to discuss legal questions. But I want to include others in the conversation, so we should figure out which forum is the right one.
I think organizing stakeholders in a heirarchical way is an effective balance between up-front decision making and “the veil of decentralization”. It is anonymity in a group, you identify with particular group(s) of stakeholders and (if that group is sufficiently large) you can’t be held personally accountable for the decisions of the group (as long as your decision is not broadcasted).
Treeing up to an organizing layer like the Magicians (organized through Rings) would be an effective way to funnel this conversation from it’s most broad to narrow enough to advise Core Devs on the implementation of a proposal.
That, or we just go full politics and elect a rotating body of “trusted community members” at a 1 year interval to advise the Core Devs of community sentiment in any contentious decision. Very similar to @AFDudley’s quip about political whips.
Small preface - I’m writing as an individual here as I’ve decided to part ways with Truffle. These words/opinions are my own.
Just wanted to mention EIP-1193 (provider API standardization) as a potential case study for this. @nivida and other devs involved believed in earnest that they’d reached consensus and released a change to web3.js based on the draft EIP as web3.js@1.0.0-beta.38. Unfortunately some fairly significant parts of the development tooling ecosystem (myself included, at the time) weren’t aware that this change was coming and only learned of it when our users (Dapp developers) complained that web3 was erroring when initialized with providers that hadn’t yet been updated for the change.
This issue is water under the bridge as far as I’m concerned (major appreciation to @nivida for this!), but I think it’s worth looking at in a retrospective context as a case where contentious review happened after the point at which the lack of such review would impact the community, and a case where unknown unknowns (e.g. how providers are used by web3, who produces these providers, and how much of the community consumes them) caused a fairly significant disruption to the development community.
So a lot of JSON-RPC layer is not considered a Core EIP — it doesn’t affect consensus.
Of course — it’s extremely Core for Dapp developers!
I think this is a perfect example of where having all the stakeholders in JSON-RPC — from tooling to wallets to dapp devs — come together and be an expert group around this.
Interestingly EIP-1193 wasn’t even a JSON-RPC concern. It’s defining a standard for an application level concern that pertains only to JavaScript Dapp clients.