EIP #904 “Community Veto” was created by GitHub user sfultong in order to create community veto powers as well as clarifying EIP acceptance procedures in the case of Core EIPs (e.g. improvements requiring a consensus fork).
Several key comments helped clarify the process and opined on the appropriateness of a community veto or vote.
What can be learned from these comments is how a Core EIP proceeds to an implementation and acceptance by the All Core Devs group, becomes implemented in clients, gets activated on testnet, and gets activated on mainnet (the hard fork event).
Viewing the All Core Devs proceedings would also be instructive.
Here, I am focusing on comments that shed light on the process:
MicahZoltu commented that the process gives the community an opportunity to “indicate their dislike by not upgrading their nodes to run protocol changes. The community’s role in the governance process (currently) is that of final veto power.”
Arachnid commented, pointing to a gap in the current process: “nothing that says hard forks have to use EIPs exclusively to describe changes. That process could definitely use formalising and improving.”
gcolvin commented: “when it comes to changes to the clients the developers of the clients call the shots. The EIP process only provides input. So you can’t actually prevent the core developers from considering an EIP.”
cdetrio shed a lot of light on the full process in his expanded description.