Currencies like Etherium and Dash pride themselves on having implemented voting in their system so they could make changes faster than bitcoin.
Where does Monero stand on this? Are there any provisions for the 50% to be able to impose their preferences on everyone else, or is it like bitcoin, where consensus is notoriously difficult to reach?
There isn't a "formal" voting system if that's what you're asking. Anyone is free to fork the project and "vote" by making changes he wants. Already happened and that's how we got the current awesome team.
There isn't a need for a formal voting system of any kind as that would mandate some central authority tallying the votes. Even if everyone votes, what is to force a dev. group to go with the majority vote? You can vote all you want, but someone has to write the code. It all boils down to trusting a group of developers. If they are widely trusted, then they will be allowed to lead the project and continue to smoothly improve. If the trust is lost, the project comes to a road-block and needs to fork its way to continue. Natural selection, one could say.
On the other hand, we have the forum funding system, where funds are raised for specific goals, so you could say people are voting with their money.
Maybe we should look here for some good ideas on governance, but that's just me :)
There's actually a formal voting system among the core developers, when it comes to crucial decisions. Like the regular schedule of hard forks, it's designed to not get stuck like Bitcoin. Vetos are discouraged, discussion on IRC will often be enough to reach consensus, and minor changes are implemented without much debate (listen from 26:40).
The voting system that the Core Team uses is based on the CentOS voting system. Votes are not cast permanently, so a member can cast a vote at the beginning of the meeting and change it several times throughout. In order from disagreement to agreement, the following votes can be cast:
Veto vote (-1). This is generally discouraged, unless it is accompanied by substantive arguments rooted in project-relevant criteria (protecting the community, economic reasons, technical reasons)
Reservations vote (-1 or 0). Either a neutral vote, or a negative vote, coupled with reservations and concerns that are stated with the vote.
Stand aside vote (0). A neutral vote, which can be accompanied with some reservations, but which does not seek to block the vote.
Supporting vote (+1). Supports the proposal / idea / change. The voter would be expected to also indicate whether or not they will personally assist in driving the effort if successful.
In the absence of any vetoes, the votes are tallied, which gives both the result of the vote as well as an indication of the amount of support (or lack thereof). If the votes add up to a negative or positive amount then the outcome is clear. If the votes add up to 0 that is normally an indication of no support and only small reservations, in which case the matter is not blocked by the vote, but it is also not particularly supported. In this event the Core Team may choose to hold another vote, optionally at a subsequent meeting a week or two later, if the matter is such that it requires more positive support.
Our hope is that this process will prevent Monero from falling prey to "design by committee", but also prevent "design by Wikipedia" or "design by the person with the loudest mouth / most eloquent writing". This process is currently up for discussion and comment; please feel free to provide input on it.
