2/ This and the fact that they are technically competent, make them the most qualified to drive the technology forward. Not the masses.
-
-
Replying to @hugohanoi @phildaian and
3/ A better way than “making the set of engineers explicit” via some form of election, is to leave the development process open (as it is now), but do two things:
1 reply 0 retweets 0 likes -
Replying to @hugohanoi @phildaian and
4/ a) have complete transparency (public peer reviews) and b) define an objective standard through which we can evaluate technical changes.
1 reply 0 retweets 0 likes -
Replying to @hugohanoi @phildaian and
5/ The BIP process is already very close to this system (although I’m sure we can do a better job in terms of defining the objective standard). Part of the reason people mistook the block size for a political issue is because we don’t agree on the objective standard.
2 replies 0 retweets 1 like -
Replying to @hugohanoi @phildaian and
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.
1 reply 0 retweets 0 likes -
Replying to @hugohanoi @phildaian and
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.
1 reply 0 retweets 0 likes -
Replying to @hugohanoi @phildaian and
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.
1 reply 0 retweets 0 likes -
Replying to @hugohanoi @phildaian and
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.
1 reply 0 retweets 1 like -
Replying to @hugohanoi @phildaian and
> Again, contingent on the fact that we define the common objective standard clearly. IMO this is impossible.
1 reply 2 retweets 5 likes -
Replying to @VitalikButerin @phildaian and
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.
2 replies 1 retweet 1 like
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.
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.
