Slight process improvement ideas: Deferred Proposals and Community Support

Process Improvement
1

Hi all,

Sorry I couldn’t join the fun in Berlin, I’ve been at a wedding all weekend. I’ve been following a lot of the developments from the meetup and what’s been going on with EIP-999 on twitter and other channels (AllCoreDev gitter / Governance gitter).

After chatting for a bit with @fubuloubu in the Governance gitter, we had a couple of potential process improvements to float to you all for feedback.

First: In EIP-1, the Last Call rejection bullet (under Drafts) is written as “:x: Last Call – A request for Last Call status will be denied if material changes are still expected to be made to the draft. We hope that EIPs only enter Last Call once, so as to avoid unnecessary noise on the RSS feed. Last Call will be denied if the implementation is not complete and supported by the community.”

Can we change or strike that last line if it is not referring to community support (sentiment)? It gives the impression that to move to Last Call community support (positive overall sentiment) is required. I’m not sure if that is what is meant or if it is supposed to mean “supported by the clients.”

Second: One of the problems I’ve been seeing is that there isn’t a clear path for rejection or deferral of proposals that lack community support. I don’t think that’s a bad thing (especially outright rejection), but I think it creates a situation where the governance process may halt on proposals lacking clear support leaving them in Draft status for what seems like forever (either stuck there, or endlessly looped back from Last Call > Failed Acceptance), which does not signal appropriately to the champion/author. For EIP-999 since it is likely meant to be included as some future planned hard fork, there’s no value in leaving it Draft / Last Call and continuing the discussion without any clear change in community support once it has become clear it won’t be included in the next “scheduled” hard fork due to that lack of support.

@fubuloubu reminded me of the deferred status and had a great idea, I think to help with this problem. If a core protocol proposal can not proceed past Last Call status, which as I understand it can occur for a number of technical review reasons/unaddressed issues (reverts back to Draft), or because philosophically controversial proposals lacking clear community support aren’t included in ETH Core Dev call agendas and thus cannot be voted on for Acceptance, that the proposal be moved to Deferred status. @fubuloubu proposed that the champion can then petition to have the EIP status changed back to Last Call after demonstrating there is clear(er) community support, and the controversiality of the proposal, and the proposed changes, no longer pose a threat to the ecosystem. I dig this idea as a way back from deferred to active consideration for inclusion in the subsequent scheduled HF (assuming it’s not something critical enough to warrant an out-of-band fork).

I realize this relies significantly on signaling and better metrics for gauging support. So in the interim, focusing also on defining better ways for gauging such support is critical, and I know already Work-In-Progress.

Please let me know what you think.

Cheers,
Andrew

2

That is my understanding as well. Last Call is that there isn’t technical problems with the EIP.

It then enters the undefined Core Dev process, who (especially for items that can only be included / implemented in a hard fork) may want support in understanding community sentiment.

So - one of the action items is that the EIP process is relatively clear — but the Core Dev process is not.

(The EIP process) —> Acceptance (no technical issues) —> Core Dev process of whether / when / how code / spec / change will be included in rollout.

Don’t know how to indicate / highlight in the EIP process that this is waiting or not for some Core Dev action.

Diagrams welcome!

1 Like
3

So this is where I think the current process sort of breaks down. As I understand it, there needs to be clear consensus/support from the community before such philosophically controversial EIPs are added to the Core Dev meeting agenda for a vote to move to ‘Accepted’ status. If there’s no clear community consensus it isn’t added to the agenda and remains in Last Call status until such a time the some clear support from the community is observed. The other option is to ignore community support behind it, and put it to the ETH Core Dev Vote (which I think sends the wrong message), and if it does not pass for any reason, sends it back to Draft state. Right now the process puts it on the champion to wait for clear support before even submitting the EIP… but that’s obviously not going to happen, so I think there needs to be a way to get the ones that don’t have support out of the way, so time isn’t continuously spent rehashing the same points without much of a change in overall support. I think that’s where the Deferred status + petition for reinstatement to Last Call comes into play, which signals it is not up for further discussion until demonstrable evidence of community support can be shown. Then it is put back to Last Call and up for inclusion in the ETH Core Dev meeting agenda and vote to move to “Accepted” status.

As I believe someone mentioned before, the core devs cannot be compelled to vote on proposals that don’t have community support, simply based on technical viability alone. That creates interesting issues of liability.

4

Well, the EIP process is not built to do anything other than technical review.

So it’s the Core Devs problem since they are the only ones with the power to actually accept it.

  1. EIP —> 2) Community acceptance process that is owned by Core Devs —> 3) Core Dev Process.

Oh, and if Core Devs don’t think something is contentious, they don’t have to do (2).

But by refusing to take on (2), that’s a decision too.

Likely, (2) is “please make a signalling proposal” with more tools being in process of being built.

There is no EIP that covers (2) or (3).

2 Likes
5

So after a proposal hits Last Call it effectively exits the EIP process and enters the All Core Dev process (vote> acception / rejection > implementation/return to EIP process)?

So rather than Core Dev rejected proposals back to the EIP process in Draft or Last Call status perpetually stalling, can they just be Rejected?

6

Why must something be Rejected forever?

By what process does a not accepted by Core Devs proposal get resubmitted?

Why / how was it rejected by Core Devs (majority vote on call)? If it was rejected because of community signalling, can new signalling re-open it?

Do Core Devs ask champion to make a “request for signalling” proposal to aid in acceptance decision?

“Somebody” within Core Devs needs to define their process if they would like transparency and repeatability.

7

Nothing is rejected forever, but there needs to be a way to come to a decision either way on a single EIP otherwise the process becomes inundated by it. Also, perpetual draft status doesn’t exactly signal the real state of the proposal to the community or the author/champion. It can always be resubmitted in the future.

So I found out from @AlexeyAkhunov that there isn’t actually a formal vote, just a discussion in which objections can be brought up. The problem is as Alexey mentioned, there’s a likelihood of Core Devs not speaking up one way or another out of fear of action taken against them, especially on controversial proposals. There shouldn’t be a default here either (e.g. not saying anything = yes) because that attributes a vote that wasn’t given. So on further discussion with Micah, I think this process adds nothing but complexity and risk. If the point is to determine technical viability that can end after Last Call, and auto promotion to Accepted status. Clients can then make their own independent decisions on implementation with knowledge of the risks in doing so.

In my previous post, a rejected proposal meant a Core Dev voiced objection, which under EIP-1 sent the proposal back to draft state. I’d rather see some finality there in that if it is objected to it is updated to Rejected status and must be resubmitted for reconsideration (knowing that is unlikely to change anything). This signals a more accurate state than simply returning to draft which signals it’s still an item for discussion.

I’m not sure if the loosely defined Core Dev process adds anything thinking more about it, but I do like the thought of someone gauging sentiment / support somehow to avoid controversial EIPs from being implemented, but that’s my own self interested perspective of not wanting Ethereum to kill itself with contentious HF after contentious HF. There’s a lot of risks and impact to the community / ecosystem for continuous contentious HFs, many of which negate the benefit of recovery proposals.

8

One possible reason would be so that when new entrants enter the repo and start reading about EIPs they understand better what is active and what is not.

I was thinking about this and perhaps it’s as easy as adding an automatically generated item in the header that notes the date of the last comment on an EIP and maybe the text turns red after X months. In this way, it would be easy for newcomers to understand that an EIP is stale.

9

Here’s one attempt: github dot com/ethereum/EIPs/issues/898#issuecomment-367942142

And here’s another: github dot com/ethereum/EIPs/pull/904#issuecomment-369381798

Also note that “Core Devs” is not based on any kind of membership, but on participation. Anyone is free to join Core Devs calls, to listen to past recordings, to describe the process, and to propose changes or improvements to the process.

1 Like
10

FYI, there is an open PR to improve the language in EIP 1: github dot com/ethereum/EIPs/pull/1224

Feel free to copy your comments/suggestions over there.

1 Like
11

Yep, I understand that participating is how one becomes a Core Dev. Thanks for the two overview of process – very helpful!

The discussion at the EthMagicians event was that Core Devs need to define the process. That may well include understanding who has standing to comment / vote / block / approve / not approve. The “we’re not going to touch this one because the community maybe doesn’t like it” is probably the part that needs the most work.

Core Devs are the only group that can currently accept / reject items core to the protocol. Quoting from Nick’s 898 comment: “If the participants agree it’s a good idea” is not a repeatable process :slight_smile:

You probably want to keep deliberations to technical review, so you likely don’t truly want everyone to participate – i.e. non-technical people who don’t work on code.

From your 904 comments on two different types of Accepted, I think Accepted is accepted – no technical barriers. Separate is whether or for which HF an EIP might go into. Maybe “Scheduled” or “Sentiment Review” are useful labels?

I’ll review those steps again.

And of course the whole “does ERC process follow EIP process” – ideally, yes, with EIPs having the separate, second process of whether or not it gets planned for inclusion.

ERCs can be finalized without a Core Dev step, as adoption is really up to implementors of tokens or whatever standards are being referred to in the wild.

1 Like
12

I’d like to see language devs have an input into the ERC process. There may be ways we can all choice to better support a new standard or barriers to us implementating proposed ones in certain languages.

In fact… Should be have a “Lang Devs” ring?

1 Like
13

You mean, like Solidity vs. Vyper? Super interesting, would be great to have multiple implementations.

We’ll see how many rings explode into being in the next little while :slight_smile:

1 Like
14

Any Ethereum language: Solidity, Vyper, Flint, Bamboo, etc.

Coordination on: ERC proposals, compiler integration into frameworks, ABI spec, ethPM, tooling integration, natspec/radspec, etc.

eWASM and smart contracts in Ethereum 2.0

Basically, anything that touches source code and compiler outputs (before it goes on chain)

2 Likes
15

I don’t think “Tell the Core Devs they need to define their process” is a very useful actionable. First of all, the tone takes an “Us vs Them” approach. Also, the entire problem here is that the Core Devs process cannot be articulated in a foreign language. So it would be like landing on the shores of Corinth and saying “Please define your governance process.” The Core-inthians can only respond, “We can’t understand what you are asking because we only speak Corinthian, not English.” Then the foreigners stomp up and down and demand, “take us to your leader!” So the Corinthians invite you to their ceremonies and then everyone is trying to make heads or tails of what is going on.

If you ask the Core Devs to define the process, the best answer you’re going to get is “we have an open conference call. People talk, and then a decision is either made / resolution recorded by updating the EIP status. Or a decision is not made, and we schedule another call to follow in two wooks.”

I think a better approach would be to witness Core Dev calls, or listen to past recordings, and try to understand what is going on like an Anthropologist would do when landing in a foreign land where the natives are speaking an unintelligible language. Then try to describe the ceremony. You might end up writing a document like The Tao of IETF
 or On Consensus and Humming in the IETF. Some people may not like that decisions are made (or not made) based on a humming ritual, or that the power structure is not formally defined. But it is what it is (though it can and will evolve and change).

That’s kind of true by definition, isn’t it? If you implement a protocol feature, then by definition you are a Core Dev. So that’s just a way of saying “only core devs can implement protocol features” - true by definition.

Well, I wrote the definitions of the Status terms that are on the README at present. For simplicity, I restricted the definition of Accepted to mean “planned for inclusion in the next HF.” The rationale here is that planning out a roadmap of multiple future HF’s is too complex (or can be done elsewhere than Core Dev calls / EIPs), so here we’ll just plan one step at a time.

About 18 months ago, I (and others) had aspirations of forming a new process to govern just a subset of the ERC’s - only those ERCs which affect the RPC methods. I outlined the process in an pre-draft EIP, “Universal specs for JSON-RPC API methods”.[1] The process would be based on new signaling tools/dapps. We (myself, Dan Finlay, and Andrew Milenius) started building those tools at an IPFS-Ethereum-hackathon organized by MetaMask in Seattle, tentatively named EipSignal.[2]

We tried to organize a working group to continue making progress building those tools with some Consensys people (Russell Verbeeten, Saraswathi Subbaraman, and Eric Tu, among others). Some good progress was made, but the working group eventually fizzled out. It was unfortunate because we even had an identity registry that would’ve been a useful bootstrap for a voter base.[3] But the working group just did not have enough bandwidth to take these Proof-of-Concepts into functional usable governance tooling, apparently, in the 18 months since we started. Not to mention other attempts at governance/signaling tools (at least two off the top of my head [4]).

So in conclusion, I think a better approach, rather than demanding Core Devs to clearly define their process, is to lead by example and build the tools to demonstrate a better process. But its going to be a lot of work (because building software is hard) and it might fizzle out. If tools get built and the community starts using them, perhaps the Core Devs would see “hey look, the EthMagis have a ceremony where a bunch of people signal their preferences by waving glowsticks around, and then cargo is airdropped from the sky.” Then they might copy the process. Kind of like the way CarbonVote was watched by the Core Devs, and then adopted into the process to determine the default fork-or-dont-fork flag in geth.

  1. github dot com/ethereum/EIPs/issues/217
  2. github dot com/MetaMask/IPFS-Ethereum-Hackathon/issues/14
  3. github dot com/pipermerriam/devcon2-token
  4. github dot com/ethereum/stake-voice and github dot com/vulcanize/ethersignal
  • sorry, forum telling me that I can’t post links.
3 Likes
16

Thanks this is great!

Definitely not us vs. them. More like, when asked in the room, EthMag attendees and some Core Devs can’t speak for all Core Devs (which was asked).

Definitely agree we’re all in this together and wanting to help improve.

IETF mentioned a lot as inspiration.

Looking forward to more work together.

17

NICE FEEDBACK! And glad you were able to find our riot channel working on the signaling website… for everyone else: http://riot.im/app/#/room/#ethsignaling:matrix.org

2 Likes