Voting mechanism

[Dexaran]

Title: Voting mechanism for Ethereum Classic
Author: Dexaran, dexaran820@gmail.com
Status: Draft
Created: 3-05.2017

Abstract

The following describes a simple version of the governance system written in smart contracts, which is able to work completely on-chain without any interference from the outside world.

Motivation

Decentralization is one of Ethereum Classic fundamentals. However, such aspects as "official reddit page", "official logo", "official twitter account", "official github repository" are completely centralized. There is a minority of the community who decide which voice should be considered official and which one is not. This all is governed by certain people.

It appears that only on-chain decisions can be really decentralized and unbiased. As a result, it is necessary to implement an on-chain system that allows members of the community to cast their votes, thus participate in decision-making.

Specification

https://github.com/Dexaran/Onchain-Governance-System/blob/master/vote_system.sol

[sjmackenzie]

What's your thoughts on reaching a rough consensus through executing code?

[Dexaran]

Do you mean smart-contract based voting?

[sjmackenzie]

https://sjmackenzie.gitbooks.io/rfc/content/spec:2/COSS please read this.

[Dexaran]

@sjmackenzie COSS is basically similar to the ECIP process analogue. I think this could be a good decision to use COSS to formalize the process of communicating with developers and making decisions.
In this ECIP I was aiming to design a mechanism for receiving feedback from the ETC community, including ETC holders, market speculators, miners and others who are far from technical specifications.
It seems to me that COSS can not be easily used by these individuals.

[sjmackenzie]

With COSS it's not necessary to have a vote based system. We just arrive at stable specifications through rough consensus via working code. A community that only comes up with grand ideas but no implementation will wear down the development team with hairbrained ideas. The "through working code" is the filter, it also opens up a potential for development contracts for the developers in the community in that if the proposer cannot do the implementation to push it to draft/stable themselves s/he'll need to contract someone to push the raw spec to draft then collaborate and demonstrate via working code why this direction is good. If they're not prepared to put their money where their mouth isthen maybe the idea wasn't so hot in the first place? Should the greater community agree on the benefits then 3rd party implementanions may start to implement it. At that point the spec becomes stable.

[Dexaran]

Do you think that when making a decision, only the opinion of the programmer (the person who can create the code for the demonstration) should be taken into account?

[sjmackenzie]

No, but when making the case that this spec should be made stable, then it's assessed based on executing code and a decent spec. Secondly when the spec is in raw or draft or for that matter any phase a non-programmer can easily read the spec so this process doesn't exclude non-technical people. Ping the relevant parties with the spec URL and possibly give a translation and you've got a large base already covered. Discuss working code, something that can be tested and prodded easily, even non programmers can test that stuff out and give feedback in the form of issues on the issue tracker.