kennyrowe
commented
6 years ago Yep - agreed. This was a very rough copy of EIP. Needs work for sure.
Open Jake-Gillberg opened 6 years ago
kennyrowe
commented
6 years ago Yep - agreed. This was a very rough copy of EIP. Needs work for sure.
nashef
commented
6 years ago One of the issues that came up at the governance conference is that many improvements have to be implemented by developers. RChain may not control enough of the developers to simply get everything the membership wants, even if a ballot is approved. One argument made at the governance forum was that it's a bad idea for the RChain Cooperative to control a majority of developers, because this makes the Coop a single point of failure for the community. If the Cooperative doesn't control the majority of developers, then it should not be assumed that the Coop Membership's features will simply be accepted without pushback from the technical team.
As a result of this, our process framework needs to capture both the idea of member intent and the idea of developer/technical intent. One possibility is to have a kind of "community improvement process" that's interleaved with a "technical improvement process." Then, create an explicit recognition of potential conflicts between the two. For example, the dev team may feel that the correct technical move is to implement feature X, while the membership thinks that this is a bad idea. As you consider governance process for RChain, I would try to explicitly design this in in a balanced way. Somewhat like having a bicameral legislature.
BitCoin lacks this and the result is a comedy of forks driven by miners and no clear direction forward. Ethereum also lacks it and their result is that decisions are being driven entirely by the dev team with little or not input from critical stakeholders like network operators, token holders, and app developers.
RChain Coop can and should strive to be a Pareto improvement on the situation by creating a governance model that recognizes the important role of all these stakeholders and gives them a place to express their views and wield an appropriate level of power and autonomy.
Regards,
Nash E. Foster Founder Pyrofex Corporation
jimscarver
commented
6 years ago Yes, solutions decided among stakeholder groups tend to be significantly superior to pure democracy. We want to make good decisions so a multi-stakeholder governance structure RBI seems appropriate. I suggest liquid democracy selected stakeholder group representatives consenting to leadership. Some structure is necessary to forestall dysfunction. The patterns of decentralized governance may be encouraged at every level along with other collective intelligence best practices. Our voting system that will be available before the meeting is TBD. In the meantime sentiment can be gauged by reactions and discussion here and on discord. We might use loomio as well. It need not be decided today. We just need a good way to submit RBI's and this seems to be a good start.
If this is a process to define a ballot item, it seems like these statuses don't quite map appropriately.
In what status is an RBI that has enough support from membership to require consideration by the board, but has not yet been approved by the board for inclusion in the annual ballot? In what status is an RBI that has enough support from membership for consideration but is denied by the board for inclusion on the annual ballot? (Actually, on a second read it seems like deferred would be appropriate here) In what status is an RBI that is approved for the annual meeting, but the vote has not yet been decided?
Also, I think it would make sense to remove the language about "hard forks" here: Ballot items may be organizational, or do not require hard forks to implement. In this case it doesn't make sense to tie the status of "Finalized" to "Implemented in the previous hard fork".