Dismantling the core team and governance structure

@lehnberg something I don’t hear mentioned much, but which I think could be improved on with great benefit to the project, is separation of implementation vs protocol.

Currently the protocol specification and software implementation exist as one, governed by one body. This makes it hard for new alternative implementations to arise, partly because the protocol is not clear (you basically just have to read/infer from the reference implementation), and and partly because the protocol is subject to change with the reference implementation without consideration of or notification to other projects/teams; hence, its difficult for a new team to invest in an implementation, when the protocol may change under their feet without having a say or even notification of the change. A few projects have been left out to dry, because the core implementation changed the protocol without considering the needs of other wallets/teams. This makes it very difficult to foster a diverse ecosystem.

The job of managing a software project is very different from the job of designing a protocol. Both have very different incentives and tradeoffs. The implementation team would benefit in many ways by having a tight, centralized team focused on building the product with quick turn around, bug fixes, sexy features, etc.

The protocol specification on the other hand would benefit from a highly decentralized team/RFC process that only slowly evolves as consensus gains behind RFCs. This becomes even more effective as multiple implementations arise, and soft forks allow building consensus behind different RFCs.

TL;DR: the reference implementation and the protocol are two different projects with different requirements. They require different types of leadership to meet each of their needs.

3 Likes

I feel like people are just mad because mimble wimble had so much hype and they were expecting a get rich quick scheme. And then a year after they are not rich and trying to blame the devs. Although they won’t take into consideration that crypto like bitcoin, eth, monero, etc took 5-10 years to get popular. And this is an open source project that takes time…

The devs have done a great job at keeping the core simple and secure. Which sadly mainstream crypto could care less about. They prefer a blockchain that is 500GB in size that no one can actually run. Most investors have no idea what crypto is and just buy it for the name. Eventually, those will crumble under their own weight but might take all of them down.

And then there is the whole ASIC part and User error part. If we could actually get a manufacture to produce one it would really help stabilize the network. And sadly the user error part is hard to fix.

Grin just needs a breakthrough whether that is from a user experience evolution or a security flaw in some of the other major cryptos… We just need something going for Grin and then everyone will be happy again. Instead of non-acedemic articles being written shaming Grin and stating its dead… Maybe that’s it. Maybe we need some MARKETING.

3 Likes
Off-topic: Who's hacking what, and the pros and cons of tx monotonicity

Funny; I think “all kinds of hacks” could describe your one-sided tx proposal. And “simple tweaks” could describe our wallet (re)play protection rules.

Meanwhile, giving up on transaction monotonicity seems like a weakening, not strengthening, of the base.


mod: off-topic, hiding

3 Likes

Thanks for contributing a proposal!

“Separation of power” is in general something that seems to work in order to keep powers of institutions checked in, there are many examples of this applied elsewhere:

  • Church and state (and nobility in the past)
  • U.S. Constitution, House of Representatives, Senate
  • The Crown (not the Netflix show), the House of Lords, the House of Commons

It does come with trade-offs. You gain checks and balances, you lose momentum and ability to reach agreements on what to do easily. And it inevitably adds layers of politics / bureaucracy. I don’t know whether Grin is mature enough in order for such systems to make sense, or whether it would just lead to more in-fighting and stalemates. Can you share more of your motivation behind proposing it?

In your example you list three powers. If we assume that each power has an equal amount of members, and that the power of the purse is a 3 of 5 multi-sig, we’re talking about at least 3 * 5 = 15 different individuals. The current members of the core team are 7. If we were to implement this, we’d need 8 more individuals to be chosen. Do you think we have obvious candidates in the community today? How would they be chosen? How long would they serve for? How do they get booted out, how do new members get added? What happens at disagreements?

And more philosophically, isn’t it more a matter of “the Power of Consensus changes” rather than the “Power of the Repo” we’re talking about? Or are there examples of PRs being rejected unfairly?

And as others have pointed out, isn’t Power of Direction and Power of Consensus changes very similar?

1 Like

Thanks for making a proposal!

On the contrary, it doesn’t sound radical at all to me. Aside from dismantling the core team and picking 5 new members to hold keys the multi-sig, what is achieved here? And how is anything improved? Do you think the main issue we have today is not with the fund or the governance structure itself, but with the specific people who hold the keys? To be clear I don’t mean to be defensive here, I want to understand your rationale better.

How long will the new multi-sig key holders hold the keys? How does the spending mandate differ from today’s?

There are explicitly no vetoes today, what you describe (to me) sounds exactly how decisions are being made today. What’s the difference?

A quick side-note on rough consensus: If you have a single senior and well respected member of the community making a proposal that does not convince other senior and well respected members, the default action becomes do nothing. It’s a consensus seeking process. It’s not enough to argue the superiority of your idea. We acknowledge that we cannot always agree on everything. We also acknowledge that we will not let a single individual block progress in the opposite scenario where everybody else agrees on a direction.

The purpose of my proposal isn’t necessarily to change the decision process, but to make Grin more approachable and open to new contributors. It’s about the feeling. Having a governance page on the only grin website with faces and names of official core team leading the project, really doesn’t encourage an open atmosphere.

And no, I don’t have a problem with the current multisig holders, I just want to separate them from any other perceived stance of “official” power.

1 Like

Hey @energyburn, thanks for this!

What you talk about (whether spec or implementation should determine what the consensus rules are) was last being discussed in aug 2018, i.e. six months prior to mainnet. Your question made me dig quite a bit to find it, see here: Meeting notes: Governance, Aug 28 2018. There’s also the full gitter transcript you can browse here.

Relevant section:

3. Formal specification for Grin

  • Discussion about approach for formal Grin spec for implementations to adhere to.
  • Main options are the ETH approach (colored paper) vs BTC approach (where main software is canonical).
  • Question is relevant as there’s already a Go implementation effort for Grin (albeit it appears to be dormant).
  • Each approach has drawbacks, it will be a challenge to keep documentation up to date, and it can be quite opaque to interpret the reference implementation. Add to this that current state is in flux and changes rapidly.
  • There’s already a documentation effort underway as part of https://github.com/mimblewimble/grin/blob/master/doc/toc.md , while not a formal coloured paper, it might act as an in between solution for now.

Decision

We will use TOC.md for the reference implementation spec for now. Anyone who wishes is happy to contribute. Once this is stable/polished enough, it can then be converted into a formal “coloured paper”.

Not that much has changed in the reasoning since then I think: Keeping a formal spec up to date is hard, and it’s not clear what happens when there are discrepancies. There are pros and cons with each approach. We’ve not felt comfortable doing a formal protocol spec yet, (but maybe this will change after HF4?). That said, if somebody wants to go about doing it, they are more than welcome to, preferably alongside ideas for how to keep that up to date and accurate.

Regarding the governance process of making protocol changes versus making changes to the software implementation, I’d argue that there’s already quite a degree of separation there: Consensus breaking changes require going through the RFC process. In contrast, releasing a new version and features of the node implementation (without consensus changes) takes a quick agreement amongst devs and can be turned around in days, see for example the recent discussion around version 4.1.0 on keybase.

How do you think we could improve further here?

1 Like

The motivation for adding the page in the first place was that we were being criticised by other people in the community for being opaque and hiding, and that we should be more transparent and open about who’s in what team etc. Seems there are a lot of conflicting opinions about what makes the project approachable and open. (:

@lehnberg Can you explain what was the purpose of forming a core team in the first place? And what is its practical significance today?

One of the main reasons for creating the technocratic council, or technomity, was to have a group of people that managed the mu-sig for the security audit donations. During this period I’d still describe it as Igno having final say on all matters, with anybody (not only us) being able to be involved and share their opinions. They set release milestones, including launch date, and what features to target (mainly).

After Igno’s departure, the RFC process (RFC0001) and the governance structure (RFC0002) was introduced as a way to formalise a process for making changes and making decisions.

In terms of its practical significance today, as I write in the original post above:

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

A successful proposal should at minimum be able to have clear answers as to how these tasks should be handled moving forward, or what should happen to them.

1 Like

We must trust only to people who trust grin and have grin in wallets 1grin 1voice. We investors in GRIN want to have our voices in Grin Government. People who dont have grin not able to care about grin. We investors must have major part in Grin Government.

@lehnberg Let’s address each:

Some of the current responsibilities

  • Managing keys to general fund - The only official team should be the council holding the funds.
  • Taking fund spending decisions, approving/rejecting funding requests - Same, job of the council. Most, if not all, funding requests wouldn’t need an actual council vote. But in worst case scenario where there’s no agreement, it would be possible.
  • Administering & moderating the /mimblewimble GitHub org - We don’t need a public team for that. We have several paid and volunteer contributors (such as yourself) each doing this job. There’s no need for a team structure. Have you guys ever held a vote on these kind of decisions?
  • Administering & moderating the forum and keybase - Same. Responsibility should be delegated as seen fit by those already holding the power. Why is there any need for a public team to do that? it is done by individuals, and they don’t need an entity behind them.
  • Managing non-public discussions like exchange listings - Again, don’t need a whole team for that. Coordination on those issues can happen exactly the same way as it does now even without a team.
  • Adding/removing sub-teams, like security, wallet, node - And again. Just announce a new team. You, or anybody. There’s no need for a governing body to do that.
  • Approving/rejecting project-wide RFCs, like governance - Why can Bitcoin and Monero do it without an official leadership but not Grin? Of course there’ll be practical leadership, but it won’t be structured.

Let me refer to an earlier quote of yours.

There are explicitly no vetoes today, what you describe (to me) sounds exactly how decisions are being made today. What’s the difference?

Exactly. So why do we need this Core team structure to do that?

Let’s begin to treat every one of you as an individual, with his own views and opinions.


Mod: removing quote formatting for clarity as it’s not a quote

Thanks for that, I think I understand where you are coming from better now, @Paouky.

  • Managing keys to general fund - The only official team should be the council holding the funds.
  • Taking fund spending decisions, approving/rejecting funding requests - Same, job of the council. Most, if not all, funding requests wouldn’t need an actual council vote. But in worst case scenario where there’s no agreement, it would be possible.

To be clear, this is the new council? Or the old one? Whenever you give some group keys and right to spend $1m of funds, you are creating a hierarchy whether you want to call it that or not. How long do those key holders hold this authority? How are they replaced? How does anyone question their authority?

We could dismantle the core team, keep a technocratic council, and let teams self form around topics. The council’s main focus would be to make spending decisions and manage keys to the fund. What exactly does this solve? To be clear, if it doesn’t make things worse off, I’m not necessarily against it either, as less hierarchy and structure is better if we cannot justify it.

But how does it make a difference from what we have today?

The problem has not been that the core team has been wanting to moderate the forum and keybase. The problem has been that nobody else has wanted to do so, at least not while subscribing to the code of conduct at the same time. We can remove all the structure, but if we’re the same group of people doing all the work, what’s changing really?

Anyone is free to propose a team today. Anyone is free to pick up a task today. Anyone is free to submit a funding request today.

I think there’s little gatekeeping today (correct me if I’m wrong), aside from:

  • how security vulnerabilities are handled
  • how exchange integration communications are handled

Any consensus rules change discussion would likely be playing out the same way it does today, regardless of whether there was a core team or not: rough consensus would be required in order for a proposal to be adopted.

2 Likes

Ah, thanks for digging that up! Its good to see the history of where we are.

I would argue we may be approaching the point where our reasoning on this should change (perhaps after HF4). IMO we have enough stability now that an independent spec could be maintained with “less” effort than before (although still no small effort :sweat_smile:).

I see having a separation between the two facets (protocol spec vs reference implementations) becoming more important and also having diverging needs may require different management approaches.

Unfortunately, personally I don’t have the time™️, but I hope that if any governance changes are considered, we might also consider the needs of these two diverging missions.

2 Likes

@lehnberg The council governing the funds may stay the same, It’s mostly a name change. Preferably it would be expanded and diversified over time.

But how does it make a difference from what we have today?

what’s changing really?

We change nothing. This isn’t a solution to a specific problem. It’s about the psychological effect of having a Grin official core team. It’s about the future of our community. The less structure there is, the more people feel welcome to step in with their own voices and efforts.

Do you feel me?

2 Likes

I do, curious if others do too.

Side question: Do you still see the RFC process in its current form serving a purpose in this scenario? Would it need to be altered?

Frankly I need to think about it some more, the RFC process is definitely the most interesting part. My intuition tells me to leave it as is.

You have a log of questions I dont have answers for.

In this case the idea of dividing powers between separate (non-overlapping) teams is to allow progress by being able to bypass the veto of a single/few. Its not perfect because Repo Merge power still allows a veto of a funded and coded merge request but I think it would be harder to veto an approved, funded, and coded change than it is to squish the idea before it gets traction. If somebody really hates the design of an approved and funded change, that person has more incentive to work with the dev to improve it than to squish it. Having a limit on how long a person can hold the same position would also help.

Here is an example of how the teams might work together:

  1. the Direction team decides that a 2-step transaction is desirable and creates initial RFC
  2. Some ideas are discussed and a community member (dev) adds to the RFC and makes a funding request for it
  3. Purse team thinks its worth investment so they approve funding
  4. dev implements and makes PR
  5. Repo team reviews the code and asks for revisions and then eventually approves and merges (or not)
1 Like

Is this true though? I’m not entirely sure this (inverse relationship) is as simple as this.

Yes, I think it is. The core team has always seemed like an Old Boys Club, and it seems to have gotten worse with time. When there’s so much structure involved, and decisions are explicitly in the hands of a few people, it’s really hard not to feel like an outsider with nothing to contribute.

The more structure there is, and the more decisions that are required to be made explicitly by the core team, the likelier it becomes that people will feel excluded. Also, the more decisions the core team only has to work with each other on, the more each member becomes accustomed to only looking for opinions of other core team members.

The core team is very much a clique in its current form. The only way to improve that now is for each member to recognize this and to go out of their way to avoid that mindset. Any governance change is unlikely to help directly in the here and now. I personally believe though, that avoiding the unnecessary structure which leads to this kind of exclusivity will help limit the effect with future project leaders.

2 Likes