# Takeaways from the ProgPoW Situation
While the community continues to debate the ProgPoW situation, I think it's important that we take a step back and ask ourselves how we got here and how we can improve. I wanted to add some thoughts around how I think as a community we can do better. These suggestions require buy in from various people and stakeholders in the community and there is no single person or group responsible for making this happen. Suggestions are made below for how we get there as a community.
For those not aware, an EIP is an Ethereum Improvement Proposal which suggests an improvement to the Ethereum protocol. Anyone is able to create an EIP by following the standards laid out in [EIP-1](https://eips.ethereum.org/EIPS/eip-1) and once it's drafted it enters a [defined process](https://eips.ethereum.org/).
The situation the community is currently stuck on is "how do we handle a contentious EIP?". EIP-1 actually lays out some ground rules around this:
> The EIPs process and AllCoreDevs call were not designed to address contentious non-technical issues, but, due to the lack of other ways to address these, often end up entangled in them. This puts the burden on client implementers to try and gauge community sentiment, which hinders the technical coordination function of EIPs and AllCoreDevs calls. If you are shepherding an EIP, you can make the process of building community consensus easier by making sure that the Ethereum Magicians forum thread for your EIP includes or links to as much of the community discussion as possible and that various stakeholders are well-represented.
>In short, your role as the champion is to write the EIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea.
The above sounds great but is much more complex in reality. I think this step of the process has major flaws:
1. It puts the onus of informing the community of the EIP on the author. The author has very little incentive to do this.
2. It requires the author of the EIP, who clearly wants to see it happen, to be the one to judge sentiment. Given the bias of the author, this will not be properly judged.
3. An Ethereum Magicians forum post is not on its own a good enough avenue to judge sentiment. While anyone can visit, very few do.
4. Judging sentiment alone is a problem as we have no proper way to do so. Also, what is the threshold on sentiment? Is it 80/20 and it's a no? Is it 51/49?
So to summarize, we have 4 problems we need to attempt to fix:
1. Author has no incentive to spread the EIP across the community.
2. Author has bias to say sentiment is fine.
3. Even when forced to show the community, the reach is small
4. It's very hard to judge sentiment, even if all of the above are fine.
I don't think we can ever make Ethereum governance perfect but I do believe we can do better. Below are my suggested improvements to the above problems.
### Informing the community of the EIP pipeline
I think a lot of our problems can be fixed via better up front communication. We all think each different group in Ethereum lives in a bubble but the reality is the EIP process itself is a bubble! Only a handful of people understand it and tune into calls. Forcing debates to the end of the process is not good.
In reality we have the following stakholder groups in the community
* Core Devs
* Core Researchers
* App Devs
Very few of those groups are informed or tuned into the EIP process. I don't think we can really blame them either as there's so much information to consume in this space, most are at their max. Allowing people to "subscribe" to consolidated information would go a long way. My suggestion is that some person is responsible for:
* Keeping a live visual of EIPs across the following flow chart
* Collecting a large list of interested parties from the above user groups for a monthly newsletter which explains where EIPs stand in the current pipeline. There can also be a subscribe option for anyone.
### Require a standard for discussing EIPs
While the above alone is a great improvement for communication, we still need a place to discuss each EIP across the community. Just posting on the Ethereum Magicians forum is not enough. Given the above user groups I suggest the author is required to create posts on:
* Ethereum Magicians
* Reddit (r/ethereum and r/ethfinance)
* Medium post (ideally via an official EIP publication)
* Twitter (can be a bot account that reads from medium account above)
The content across each can be the same so it's just about posting it multiple times.
### Have different stakeholder groups organize and have a representative on ACD calls
I won't act to have the perfect solution of how this election is done but I think each user group outlined above should have someone on the ACD calls to take notes and speak for that community if needed. MolochDAO is already discussing hiring someone for the "user" group. This person should have read all the relevant EIP information before the calls and be in tune with the community on the feedback given.
### Attempt to set some base standard of signaling mechanisms
Perfect is the enemy of good. While we can never perfectly judge sentiment, I think different community groups have decent ways to judge sentiment. For example:
* Core Devs: relatively small group, simple polling can be done
* Core Researchers: relatively small group, simple polling can be done
* App Devs: Perhaps a call or group formed with elected representatives?
* Users: Twitter, Reddit, etc...this one is tricky
* Investors: MolochDAO vote, POAP token votes, etc.
* Miners: Hash votes
I don't have all the answers here but I think we could start incorporating some of these signals into dashboards of some sort that go along with the EIP process.
I'm happy to discuss this with any party that thinks they can help out here and am willing to help fund efforts via Moloch, Gitcoin Grants or whatever it may be.
### Define some threshold of consensus required to approve an EIP
This is the trickiest one. We are never going to be able to definitively say we have an exact measurment on consensus in the community but that's OK. The core dev process refers to "rough consensus" which I think is fine.
I still think we should set in our minds what that exact threshold would be if we could measure.
In my opinion, it's around 80%. Meaning, if we could perfectly measure sentiment, to make a change we should have 80% community buy in to make it and anything lower would put the network at risk of split. I'm sure opinions vary here wildly.