By 
As the EOS referendum UIs and underlying vote tallying infrastructure nears completion, everyone is excited to see the governance layer of EOS unlocked and the process of rallying support for a proposal, getting it voted in by a 2/3 + 1 majority of BPs so it is implemented on the Mainnet will soon be a reality.
In my initial proposal on the referendum process, I collected some of the preliminary discussions and concerns I heard in the community and solicited public feedback to see what people thought.
I then posted my thoughts on the best way to attack the voting UI and suggested a user centered approach with a big focus on education (which is also now partially coded and being finalized for public beta testing in the coming weeks).
We even did a round table of many of the people involved in the project (Daniel Keyes, 
Some of the early conversation suggested that only the top 21 Block Producers vote on the very first referendum proposals (to mitigate spam), which was later expanded to the top 50 block producers, and most recently the top BPs in the 0.5% range (anyone collecting block rewards).
There is a lot more to this process than you might think at first glance. Actually taking referenda from the proposal phase to something that is implemented on the EOS mainnet requires special care and attention to detail. I will touch on this a bit, but expect EOS Alliance to collect all comments and considerations from the active community in their referendum series next week.
My goal with this post was to drill into the standards and process being discussed in the working groups. None of it is written in stone and subject to change based on feedback and insights from the community.
The project has evolved as new schemas and tallying capabilities become available. It is important for the community at large to understand that things will change and evolve over time.
There are a few things we as a community need to consider before the referendum voting UIs and public proposals open up. In this post I wanted to share some of the thinking behind the EOS Votes project (the community voting portal being developed as we speak).
We at EOS Tribe think it's important to share the most current conversations happening to gather feedback from the community. Everyone working on the project is doing the best job they can do for both EOS token holders and the BP community tasked with implementing changes as a result of referendum. We all welcome feedback and criticism during this process.
When submitting a proposal for referendum, there are a few gotchas we need to consider.
It's easy to get excited and the EOS community at large to start voting on anything and everything, but there are some serious concern when you start to really think it through.
These are all scenarios to think about when submitting a referendum proposal. In our current thinking, all referendum proposals must have an associated Github pull request (or publicly accessible git repository) for the changes being suggested in the proposal. People wanting to make a proposal involving code changes could submit a Worker Proposal through the EOS WPS to contract someone to code the change, test it and put the code into a pull request on the main EOS repo before the proposal is submitted officially.
Once again, even if there is a pull request associated with the proposal, we need to think about the implications of implementing code that hasn't been fully tested.
Again, it would fall on the block producers to clean it up/fix it and we at EOS Tribe know first hand that job is hard enough as it is. Being expected to test every piece of code from every referendum proposal that pops up is not sustainable. It should be on the proposer to test their code before submitting a referendum proposal.
As stated previously, we need to seriously consider the implications of code that could have security issues. Also, we need to think about who is tasked with fixing issues caused by code that hasn't been tested and think about how to scale this process in the future.
Again, it would fall on the block producers to clean it up/fix it and we at EOS Tribe know first hand that job is hard enough as it is. Being expected to test every piece of code from every referendum proposal that pops up is not sustainable. It should be on the proposer to test their code before submitting a referendum proposal.
With all of that said, there are currently four basic rules being discussed for proposals:
So let's visualize what that looks like for those of you who are totally confused. The process as it stands today looks something like the explainer graphic above. Although not perfect, in our discussions so far, we wanted to stick some basic principles...
This was the foundations of our thinking up until this point, but we welcome the EOS community to rip it apart and tell us why we are doing it wrong. It's all part of the process.
This project in it's current form wouldn't exist without the hard work of the following people:
