Suggestion to have a community feedback period for each EIP


#1

In the topic Reviewing the process leading to a hard fork, @mks0017 suggested that there should be a community feedback period. Each EIP which be allocated a time period for gathering input, voicing concerns, and having Q&As. This time period would be publicized to the community.

The full text written by @mks0017:

While I agree changes need to be made to the process and that there needs to be more clarity in how EIPs are implemented, giving the community veto powers would make governance much more difficult. Getting the community involved in governance should focus primarily on gathering input so that developers can understand the potential non-technical (moral/ethical/legal) outcomes of implementing an EIP.

I would suggest updating EIP-1 to include a period when community input is gathered before deciding on whether or not to go forward with an EIP. After it’s clear that the EIP could be successfully implemented from a technical standpoint, a period would be opened where interested participants could comment on their support for or against a proposal. This could be as simple as a weekly or monthly stickied post on the ethereum subreddit that includes current EIPs with short summaries that is open for all to comment. This would vastly increase the community’s voice in the process and would allow participants to voice their concerns. This would also allow developers to pose questions to to ensure all issues are addressed before deciding whether or not to implement an EIP.


Reviewing the process leading to a hard fork
#2

Personally, I think this is a terrible idea. Standards should be written by technical consensus, not majority vote - and they should be accepted as standards if they meet the editorial criteria, regardless of how wise anyone thinks they are.

If the standard is for a change to the chain rules, then there certainly needs to be community approval of that - but that should occur outside the EIP process. Attempting to insert some kind of community veto of standards will just lead to people standardising contentious things elsewhere, bypassing the system entirely.


#3

@Arachnid it sounds like what you’re saying is in line with what I proposed, so I’m not sure if you’re responding to my comment or sfultong’s original proposal.

I agree that a majority vote is not the correct way to reach consensus, and giving the community veto powers would make the process much more difficult. My idea was to standardize a way for the community to voice non-technical concerns to developers. If the EIP meets the editorial criteria and is technically sound, then the community should be given an opportunity to raise issue with a given EIP. There may be moral/ethical/legal issues that the community voices that developers are not aware of, so this process would help bring those issues to light. However the ultimate decision whether or not to implement the EIP would be the same process as it is currently. My proposal just adds an additional layer to allow for more input from the community.


#4

Yes, I’m sorry, you’re right - I misread your proposal and thought you were talking about approving EIPs as standards, not about deciding whether to implement them or not.


#5

@mks0017 did a way better job of summarizing what I, too was originally speaking to. Some forum for the community to voice concerns / raise additional points or counterpoints for an EIP (legal, economic, moral, other external risk). Then I think out of this forum, an informed decision as to whether to proceed with the implementation is made according to the current process.

The only thing I’d add is clarifying where and how this forum occurs in conjunction with the EIP process.


#6

I support a required public discussion period. At present, the the median EIP proposal is a shit show of abandoned ideas, poor implementations and poorly thought out concepts (myself included!) It would take a motivated person to watch every new issue and PR to find the gems that certainly do exist.

A public discussion period is a quality filter that allows people to discuss something before it is accepted as draft.

There is precedent for this type of governance in the Swift project, see https://apple.github.io/swift-evolution/


#7

There isn’t any body to “require” a discussion period, but I’d support establishing a forum for coming to consensus on whether proposals should go forward. This forum would need to be outside of the Fellowship, but would typically take up draft proposals that are Ready for further consideration. As ever, such a forum would only be input to other players in the community, but if th consensus is clear and fair the input should be difficult to ignore.