i think you have a point.Decentralization doesnt mean disorder and mess.
Workshare between team and a leadership (hidden or explicit) solves the problem.This is not big problem if you approach in positive way.
I honestly think itās true, speaking from my own experience.
But, as a not-so-famous poem says:
Only about myself I knew how to tell
My world narrow as an ant's world
No I mean is it as simple as -
āThe less structure there is, the more people feel welcome to step in with their own voices and effortsā.
I took this as a general comment and not specific to the Grin ācliqueā or āOld Boys Clubā.
If it were a simple truth that less structure = more welcoming, then zero structure would be the most welcoming. And this would definitely not be the case.
I suspect it is more nuanced than that.
Great discussion, it shows that the project is ready to change itself for the better future. I love Grin as the project and currency. I respect all the participants of the council and all the contributors, you did really well and all of you are sincere.
The main problem in my view ā the ākeeping fundsā strategy. Look guys, the crypto world moving very fast. We need to move the same speed, you have huge budget, and you need to spend it. The Grin is not conservative pension fund, it must be like venture fund, one of ten ideas boomingā the best, other not succeed ā not a problem. The fear and high responsibility are stopping the project. WE NEED TO RISK AND TEST THE IDEAS MORE! WE HAVE A BASEMENT ALREADY, LETS DO THE SECOND STEP! Council can show the community that itās open for new brave suggestions and ready to move forward.
But we need a mechanism to delegate the responsibility
- Is there technical ways to do the decentralized government ā voting with Grin anonymously?
- Letās make the contest with some reward to find the best strategys for the 3-6-12 month, with the stricture of the governance, committees, groups of projects that can be funded. The different views. Maybe not only governance but promotion, support, translations strategies and so on. Letās make some moves, let new people come to refresh the view.
- Even maybe not 1 , but 2-3 teams that can go the different ways based on one consensus of basic values and technical conditions of the project.
- Funding working use cases and projects that build infrastructure for Grin. Make the Grin Foundation do its role, separate it from core developer team. Let the funds work for the community, spend it. You get it for spending not for keeping.
- Funding not in Bitcoin ā but only in Grin, if you want work for Grin get a reward in Grin. Take BTC go to market buy grin and pay for work , it will support Grin on exchanges and make grin more respected. Use the exchanges to buy Grin, that use the latest grin technologies and support Grin community.
- Lets make a contest for promotion strategy and perform the group that can provide the service to deliver information about grin to the community.
- Lets use voting of core devs, holders, miners, exchanges, key infrastructure teamsā¦ Make a big council for important questions of development of the project. Itās better if Grin can use as a voice in voting.
4 Likes
No, I agree itās not that simple. Humans are complex and messy, so I doubt there are any simple principles that can just be followed to the extreme and still end up with a positive outcome. Iām also sure there are some people who feel more welcome when there is greater structure.
I think in our specific case though, we could afford to shed quite a bit of structure before we have to worry about it being less welcoming to most potential contributors.
One specific example where I personally feel we tried to add too much structure and formalization was in protocol decision making (the RFC process) . The excessive red tape led to a less enjoyable experience for contributors, and imho led to a premature ossification of a still-immature protocol.
Iām sure there are many who disagree with me on that, but I think we need to consider that open source contributors are largely volunteers, so making them fill out their TPS reports, follow rigid guidelines, and politic for approval from a formalized team is simply not something theyāll enjoy doing. They have corporate day jobs for that kind of thing. Larger projects with lots of contributors certainly need some formal structure, but adding that structure before itās needed is off-putting for most.
3 Likes
Agreed. This would create the right incentives, I think. Use the donated funds to buy Grin when the price is low.
What is the benefit of funding devs in Grin? They can receive Grin and then just sell it right after they get it. Not to mention that maybe there are even issues with having compensation in Grin because it has blinded amounts and does coinjoins e.g. is this legal in all countries? I donāt think getring paid in Grin solves anything unless they had funds locked, but this doesnāt sound cool when itās your full time job. Such a move would also incentivize devs to vote for features that would pump the price.
1 Like
Itās funny, I remember the discussion on the topic in the April 09 2019 governance meeting:
4. Grin Improvement Proposals
- lehnberg: Whatās the current motivation for formalizing an improvement proposal process?
- ignopeverell: To make sure these things stay up on a place thatās easy to find, and to ensure the correct versioning of proposals as they change.
- kargakis: Proposals that do not stay in issues make it clearer that they need more attention from the community.
- lehnberg: Whatās the definition of a proposal?
- ignopeverell: Things that break backward compatibility, at least for now.
- kargakis: Protocol changes mostly.
- tromp: I would expect a proposal for any consensus changes; either by hard or soft-fork.
- lehnberg: Iām wondering about the timing, why do we need to formalize things at this moment?
- tromp: I think GRIP formalization can wait until later, when we have a more impactful proposal.
- ignopeverell: Iād agree with that too, I enjoy informality.
- quentinlesceller: Maybe not right now but later I think this would be a great addition to the governance process.
No meeting participant argued for an immediate need to formalize the process, so no action was taken. Once there are more proposals that merit a formalized process, this will be revisited.
Less than 3 months later, the RFC process was first introduced. Why the sudden change? I think a lot it can be explained by the abrupt disappearance by Ignotus and the power vacuum it created, which we attempted to manage by adopting rules and processes for how to make decisions.
In the specific case of the RFC process, I actually do think it makes sense. It would have been hard to maintain a gung-ho approach to making proposals and reaching agreement without an Igno there to arbitrate and make judgement calls when necessary. But it doesnāt mean there needs to be a core team making decisions on whether the RFC should be acceptedā¦
And as weāve seen examples of, it doesnāt require much effort or formality make a first draft in order to clearly convey an idea and get feedback on it.
Removing this process today in order to replace it with unstructured ad-hoc proposals on the forum I think would be to take a step backwards. We already do a lot of proposal iteration on the forum as it stands today. Thatās my own intuition about it at least, not sure what others think.
6 Likes
A very minor benefit would be extra volume and love for exchanges. But, also, if people had their rent payments delayed because of the frequency of failing to use grin (particularly with exchanges) then maybe there would be some additional flexibility when it comes to proposed UX improvements. There are some benefits in incentivizing development by paying in grin, but I agree with you that this encourages DeFi and market buzz word crap.
Main reason I honestly think keeping funds and payments in BTC is because of taxable events. Without a formal company or anything I dont really even get how taxable events work on these funds and they should be minimized for those involved. Second reason is BTC is more stable than grin and the market mover so less likely to be a value loss when an alternative would be a gain. If it werent for the taxable events it would be awesome to throw these funds into GunBot and make it grow.
1 Like
Not speaking for David, but I believe the point is that the RFC process is ok for the final step, but it is being used as a deterrent for formulating virgin ideas. There should be more encouragement of sharing, developing and debating ideas long prior to RFC and the formal processes should not be used in a deterring fashion. Before this causes anyone to get upset, I do not believe that all the perceived deterrent tactics were intended to be deterrents, the flipside is also true and eventually an RFC needs to be written.
1 Like
Yea, you and @lehnberg are both onto something. It may well be that the RFC is a good way to help arbitrate disputes and formalize the acceptance process. But I also believe it to be a very high hurdle to get the discussion started. And of course we can just throw together a very basic RFC filled with TODOs, but itās not like a decision is going to be made based on a partial RFC anyway, so what makes it any better than just an informal forum post or a conversation in keybase?
Iāve personally not found participation to be any higher on a WIP RFC than a typical forum post, and it reaches a much smaller audience. Why do we need an official RFC before people can weigh in on ideas? Why are we so afraid to offer support for proposals expressed informally? The RFC process has definitely led to me not proposing ideas in the past, which seems like a very negative thing.
3 Likes
I do think there is some truth to what youāre all saying. There is one benefit that is see in WIP RFCās though, which is that the conversation is more structured and usually people that are technical enough participate in it which I see as a plus - forum posts often get derailed by discussions that are irrelevant to the problem/solution itself. Unfortunately, I agree that the RFC participation is low and would personally like to see more people get involved in the reviews/discussions on github. I think a nice flow would be to start off on a forum post and then transition to WIP RFC (with possible TODOs) after some things are patched/discussed, but it would definitely need more participation and we should get more people involved.
I think this is a very good pointā¦ UX seems to be below the bottomā¦ sometimes I wonder if the Core are actually users themselvesā¦ any howā¦
//initrant
Iām not in favor of Dismantling the core and the governanceā¦ but I am not a fan of any populist policy, this will lead to a complete failure, this is not a Democracy and it should never be. We need people 24/7 focused on pushing Grin to the next levelā¦ the problem I see is there is not a clear Expectationā¦ what are we supposed to expect from the Core? Iām not against RFCs, but it seems there is not a clear process regarding on how a RFC is evaluated, this discourages anyone.
For instance, the one side tx topicā¦ there is no quorum on any of the proposalsā¦ some people want to improve the usability and the user experience, because there is no way Grin will be widely adopted without improving the experienceā¦ since I want to have full control of my wallet, if we remove the third step on every transaction, I personally do not mind if one side txs are not supported (yeah, I changed my mind a bit)ā¦ but there is no solution presented from the Core to improve usability, security and privacy on the transportation layerā¦ Tor shouldnāt be the final solution, bypassing censorship is an endless game and it gets harder and harder everyday.
//endrant
What I want to know is: what should the Community expect from the Core?.. for instance, will the Core put effort on usability? if not, fine, but is the core willing to support those efforts? really support means to get involved at least on the architecture and design phase.
Also, I think that the process of evaluating a RFC should be more transparent.
I would like to see the Core more involved on helping the community when a proposal draft is delivered.
Instead of Dismantling, I think the conversation should be more about Checks and Balances. IMHO.
4 Likes
Sorry to take you as an example here @davidtavarez, but your comment does well to demonstrate what I think has a negative impact on the project and its development - the fact the āCoreā is a term so often used, and seen as one body. This is why I propose to dismantle it such that each core member becomes a unique individual. Iām pretty tired of seeing this word, and I bet core members are even more so. Letās remove this structure which has become an endless source of controversy and negative energy, and just keep the people behind it.
I believe this is where we should start. Even before we figure out what to do with RFCs.
2 Likes
Understoodā¦ then how do you keep people accountable if there is no structure? we can list responsibilities and at the end weāre going to ended up with some kind of Structure 
and thatās fine, but I think is that the influence of this Structure should be limited. Grin should own the Structure not otherwise.
I slept on @paoukyās proposal, i.e. the idea of regressing away from the current core team and sub-team structure, back to having a technocratic council that is primarily functioning as āthe guardians of the general fundā, maybe with some added admin-related stuff like keeping track of passwords and permissions. With the rest of teams and processes being self-organised as required.
Taking another look at what I originally wrote, how would pros/cons/flaws be affected?
Pros
- Clear process to make decisions
There wouldnāt be as clear of a process any more perhaps.
The biggest question would perhaps be around what to do with contentious RFC proposals (assuming weād keep this process). We wouldnāt accept them if we follow the logic of rough consensus. The problem would arise if thereās a divisive question in the community, maybe splitting opinion along a progressive / conservative division across both technical and non-technical people, old timers and new comers alike. If thereās a big rift, then a chain split might be the only outcome thatās acceptable to both sides, even if thatās a net negative (lose-lose) outcome.
But Iām not sure thatās very different from today? I donāt see how the core team would be able to run over the wider communityās will completely without there being consequences over time.
- Resistant to attacks
The same resistance would exist against attacks on the general fund, other areas would be somewhat more exposed perhaps. Itās however unlikely that something like the RFC process would be able to be subverted with sock puppets just because there were no core team. So generally, I think this would be okay.
- Focal point for project communication
There wouldnāt be a single point of contact for Grin matters, which I think is an improvement. If an exchange would need to do integration work in private, they could always still reach out to trusted members in the community via DMs and they could self organise. Not sure why weād need any single point of contact for any other reason. Security vulnerabilities are already handled separately.
Cons
- Point of centralization / single point of failure:
- For consensus changes
- For releases
- For spending decisions
- For RFC approvals
- For project leadership
This issue would go away for everything but spending decisions, or perhaps āreleasing fundsā to be more precise. The wider community would opine on funding requests, in the same way it does today. But obviously final authority lies with the key holders, no matter how itās dressed up.
- 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.
I think a lot of this would be resolved. If thereās no glamour in being a council member, and itās a purely admin task, then thereās nothing to create an āusā vs āthemā situation. I imagine it being more of an accountancy / bean counter function carried out by trusted members of the community thatās been around for a long time.
Flaws in the design
- Core team members have the right to stay for an indefinite time, there are no terms.
There would be no core team, but council members would still have indefinite terms. But does it really matter? We could introduce some key rotation scheme, but not sure thatās where the issue is, I think itās already handled automatically as old members get replaced by new.
- Only core members can add new core members / remove existing ones.
See previous comment.
- 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.
This would remain, but only for spending decisions.
- 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).
This should not be an issue any more. You wouldnāt promote prominent contributors to the council, youād instead maybe give them commit rights to some repo or some other responsibility.
- 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.
This issue would persist until the point where there are more contributors.
Conclusions?
It seems to be quite straight forward to regress back to a council that only controls the funds and spending decisions.
In hindsight we may have gone overboard with structure, process, and layers when Igno left, in an attempt to keep everything running. Adding complexity and points of contention.
What could be obvious as excessive today was not necessarily as obvious back then. Nothing prevents us from learning a lesson now and simplifying, if we think this is the appropriate way forward. A simpler and more self-organising structure is after all more in the spirit of Grinās ethos.
Still, similar to what @davidtavarez writes above, I do wonder in the back of my head whether this is actually solving some underlying problem. Is it enough to only window-dress and change perception?
Take an example:
A random new contributor joins the community and submits an RFC for capped emission. Thereās no structure that evaluates it, just a bunch of individuals. Some peopleās voice however carries more weight than others. There are random people whoāve never contributed before, arguing for the proposal. There are people like tromp (I imagine) arguing against. How is it clear to the new person that some peopleās voice matters less than others, or how our governance work? Why would it make them stick around longer? And how would it feel more welcoming? Arenāt we just making everything more opaque? Does it even matter?
2 Likes
The more I think about this matter, the more I see the resemblances with supra-national governance. Bottom line: There is no well functioning governing body today that can govern above nations. We have the United Nations and other multi-national organisations like Nato, IMF, and WTO, but these are not sovereign above nations, itās based on agreement amongst nations.
An implementation is like a sovereign state. Other states cannot decide what other states should exist or what rules they should have.
The Rust and C++ implementations cannot agree on a framework for Grin governance and expect it to be stable. Because at any point in time a Go implementation can come to existence out of nowhere that decides not to play by these rules.
Instead implementations work the same way like nations do with each other, using diplomacy and influence. In international trade negotiations, every country is treated with mutual respect and courtesy, and the rules are the same for each nation. But some nations command different authority and wield different influence in the outcome of negotiations than other nations.
What am I trying to say with this?
That this cannot be about general Grin goverance (the wider project across all implementations). It must be (I think) about the Rust implementation, the repos under /mimblewimble.
And maybe website, keybase, forum, etc ought to be clearly marked either as rust-implementation-only, or alternatively become implementation agnostic, i.e. completely neutral territory. So for example the website cannot have a governance and code of conduct section at the same time as claiming to be speaking for wider Grin. Either the website is for anything Grin, or itās only for Rust Grin.
Right now, itās a bit of both, and this is confusing, and I can imagine also annoying (for Grin++, who hasnāt signed up on any of this).
4 Likes
Thatās exactly my point of view.
To go further I would say that funding should also directed towards specific implementations (or developer/developing team) and managed accordingly to avoid any conflict.
Some kind of global marketing fund could be created if there is some kind of global agreement between implementations and the community about it.
1 Like
Yes, youāve really hit on an important point with this one. It is confusing and sometimes a bit annoying. People often ask for the official Grin website, or official wallet. I always point them to Grin.mw because I donāt want to confuse them, but Iāve considered adding caveats in the past since I donāt see it as official at all.
It has often been suggested when complaints are made that a second group with its own leadership, fork/impl, ideals, donations, etc can always be created. The reasoning given is that the core team are not representatives of grin (see the āelephant in the roomā post for more context). But then the core team proceeds to represent Grin by operating as the official leadership and protocol decision makers, publicly questioning my intentions for suggesting that maybe some exchanges should start using Grin++ to even power, treating their website as the official Grin website, calling other impls third-party, using their seemingly official positions to bring in donations (eg. Nervos), and much more. This is why I often liken it to the Federal Reserve - not representatives of, or subject to, the people, while at the same time having official power over them which they often claim to use in their best interests.
I havenāt pushed the point too much, because we barely get enough participation in governance and technical decision-making as it is, and I have absolutely no interest in ever causing a fork, which is what would surely happen if we just tried to do our own thing in Grin++. But ultimately we do need to start seeing each implementation as their own thing, not necessarily equals, but none subordinate to the other. Consider that Grin++, the 2nd most widely used node and wallet (and the most widely used by newcomers) has no official representation in the core team. So how could core possibly represent Grin, or even the Grin protocol?
Multiple, decentralized implementations are a good thing, and despite all of the Hell weāve both gone through as a result (me being treated like an attack on Grin for creating a C++ version, and the resulting loss of trust that contributed to my open campaigning against core), Iāve continued to let Grin++ be limited by the decisions made by a group Grin++ has no representation in. That limits much of the value that comes from having multiple implementations though. I wish we had 3+ implementations, working toward the same goals, each with some degree of influence so it can act as a check and balance on the others. But alas, we donāt have enough participation for that yet, which is one of the reasons Iāve been pushing so hard for more adoption now.
Imho, any solution that results in an explicit structure should either have ways of ensuring the community and other impls have some authority, or it should make absolutely clear that it is representative only of the rust implementation, and not the greater grin.
2 Likes
My input:
There is no perfect solution, everyone has their own opinions and the majority is often wrong. Thatās why itās important at the start to have a strong leader with a vision.
When you start getting to governance ideas you start getting into politics, then you realize all the flaws in political systems so almost need to reinvent the wheel( to an extent).
Rather than take some radical approach. Iād suggest considering some adjustments:
- Take a more active approach in removing inactive council/ core members- Sounds like this is already in action.
- Add active community participants with different views to the core team so it becomes less of an echo chamber, eg David, Kurt
If Grin was in government then the core/ council would be akin to the āCabinetā and some members of the community would be akin to the āHouse of representativesā .
So I would suggest we elect some independent community members to form a House of Grin representatives who have voting rights when it comes to approving / rejecting funding requests & adding/ removing members to the core(council). That way thereās more of a direct grass roots( community) impact on the direction of Grin- Giving the community more of a voice should mitigate a lot of complaints about Core being an echo chamber/ not being aligned with the community and Grin being off putting for outsiders etc.
āApproving/rejecting project-wide RFCsā, Github rights and any consensus breaking changes should still be decided internally by core and not necessarily done by some democratic voting process. If the community are not happy with the decisions that Core are making, they can lobby their elected āHouse of Grin representativesā to action change which would eventually lead to changes to the core team.
The āHouse of Grin representativesā could nominate a Speaker of the house who be in charge of representing them at any governance meetings and managing/ dealing with any of the issues that arise so that core is not wasting any resources on it.
^This is a rough draft of ideas.
5 Likes