If your governance process is "delegate everything to a privileged class called the engineers", that's fine, but it's necessary to *make this clear to users up front* and *make it an explicit rather than an implicit process* (implicit processes allows you to mislead users easily)
6/ This IMO is better than your idea of voting the engineers in. For a couple of reasons. First, just because you vote some people in doesn’t mean they don’t have political bias, or can’t acquire bias *after* they get voted in.
-
-
7/ Secondly, by introducing an election process you allow the possibility that the election could be gamed (who would be the judge of such an election, btw?). You also add a bureaucratic bottleneck that could deter potential contributors from contributing.
-
8/ Rather than doing that, OSS is about having a hands-off approach at the system input: everyone who is worth his/her salt can contribute. And enforcing quality *at the system output*: code is reviewed & subjected to a common, objective standard that everyone agrees on.
-
9/ I believe this process is a good model for the so-called “governance” of blockchain protocol development. Again, contingent on the fact that we define the common objective standard clearly.
-
> Again, contingent on the fact that we define the common objective standard clearly. IMO this is impossible.
-
Why not? eg: many would agree that Bitcoin has these high-level requirements (ranked by priority): 1) Security (immutability of ledger + secure token ownership) 2) Decentralization 3) Scalability 4) Privacy When there're conflicting goals, higher priority req takes precedence.
-
You can flesh it out further of cos. E.g.: How to go about making trade-offs, in what scenarios they are allowed. If you disagree with said standard, that’s the signal for forking off to your own blockchain.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
