Tl;dr
Solicit ideas and approaches on how best to break down the current governance structure and replace it with something new. I pledge to help write an RFC and/or shepherd it if I can be convinced it will be an improvement over the existing structure.
Motivation
Rather than making empty threats to “destroy the core team”, let’s instead embrace the thought and work together in the open to see if we can come up with a better governance structure to replace it with. It’s very possible that what’s worked well in the past may not be suitable for the future of the project[1]. The main reason we’ve evolved into today’s structure is because we didn’t see a better approach at the time, and I have no reason to believe it’s perfected or that improvements cannot be made.
Quick overview
(write below fixes and suggestions and I’ll add / update accordingly)
Some of the current responsibilities
- Managing keys to general fund
- Taking fund spending decisions, approving/rejecting funding requests
- Administering & moderating the
/mimblewimble
GitHub org - Administering & moderating the forum and keybase
- Managing non-public discussions like exchange listings
- Adding/removing sub-teams, like security, wallet, node
- Approving/rejecting project-wide RFCs, like governance
Some pros
- Clear process to make decisions
- Resistant to attacks
- Focal point for project communication
Some cons
- Point of centralization / single point of failure:
- For consensus changes
- For releases
- For spending decisions
- For RFC approvals
- For project leadership
- Negative feedback loop:
- Creates “us” and “them” in the community, those on the inside, and those on the outside
- This leads to the assumption that core team is “responsible” for the project’s direction and success, fosters complacency by non-core members.
- This leads to more work for core team, makes it more tolling to be part of the core team, which reinforces the first point.
Flaws in the design
- Core team members have the right to stay for an indefinite time, there are no terms.
- Only core members can add new core members / remove existing ones.
- There are no checks and balances. Community can protest and object in case of conflict, but nothing technically prevents the core team to going against the will of the community.
- The system sucks up contributors. Either there are no new core team members added (which is bad optics). Or you add contributors that work hard in the community and are worthy of membership (which leads to only core members being the strong contributors, which reinforces the “us” and “them” which leads to bad optics and another slew of problems).
- Because of the general lack of non-core engagement, it ends up being core team members that fill most the spots in sub-teams, defeating their purpose.
Some challenges / limitations with any approach
- There’s a general lack of engagement and contributions
- On top of that, there’s a lack of technical / developer expertise
- Ignotus left abruptly, and took with him a lot of the legitimacy and authority of the project’s leadership. There is undeniably a power vacuum in Igno’s absence where there’s no clear leader to rally around.
- We received clear show of support from the anonymous donor to “keep doing what you’re doing”, which means that I personally at least have a sense of obligation and duty to this donor to do what I think is right. I can obviously be overruled by others, but I’m not going to be bullied into doing something I don’t believe is in the best interest of the project.
My conclusion
- It’s… messy.
- For any replacement structure I think the two most crucial questions are:
- How to handle the funds in the General fund (and its keys)
- How to handle the GitHub org.
Money is what created most of the contention in the community, and is hardest to manage appropriately for a project like Grin. The rest can probably be figured out more easily.
Possible approaches
(come with your suggestions and I’ll update)
- Return the funds to the anonymous donor
- Burn the funds
- Split funds to core team members and break up the band
- Split funds between implementations
- Open application process:
- For funds with the purpose of having spent all of it before a certain point in time; or
- For new “teams” to be formed, i.e. groups or individuals, each get an equal chunk of the funds and have to work in the best interest of Grin according to their best abilities.
- Temp core teams, existing core team keeps the mu-sig keys but are not the core team any more. We have temporary core teams (say a new team every 6 or 12 months), that people somehow appoint, and they get a pre-determined amount to spend according to their best discretion, perhaps via filing a budget for it.
… what else?
My pledge
I’ll work with whoever wants to be involved in this thread, in good faith. If a proposal arises that I believe in and think will be an improvement over the status quo, I offer either to write or to shepherd a future RFC that introduces this and lobby for it.
I also pledge to heavily moderate this thread, so please stay on-topic and stay constructive, no bad faith rants or trolling will be tolerated.
Notes
[1] See for instance this article on the subject: https://a16z.com/2020/01/09/progressive-decentralization-crypto-product-management/
Changelog
- Sep 05: First draft