Proposal: Grin Governance Iteration

Governance
1

Grin Governance iteration

Tl;dr

Evolve Grin’s governance:

  • Introduce RFC (Request For Comment) process
  • Introduce self-governing sub-teams that steward and guide work in each of their focus areas.
  • Convert council into core team and define its responsibilities
  • Recognize more contributors
  • Achieve less centralization

Motivation

Background

Grin governance today consists of the Grin Technocratic Council, and the rest of the community. The council came to be as there was a need for some sub-set of community members to manage the multi-sig keys of the Grin General Fund, and it became a modest first pass at a governance structure. Over time, it has come to be that a lot of responsibilities and day to day tasks are handled by Grin council members. This puts a heavy workload on council members, but it also inhibits other members of the community from becoming more engaged, contributing more, and becoming recognized for it. Naturally this implies that either the council would have to grow large in order to be able to fit all the members of the community that deserve recognition for their contributions, or that we end up not rewarding active contributors properly.

As most decisions are taken in the bi-weekly meetings, it’s come to be that decisions take time to materialize: It can take up to 14 days just to have the initial conversation and sometimes multiples of that to reach an agreement. In these meetings the entire active community ends up participating in every discussion, in a synchronous fashion that often does not end up being productive.

We also struggle to answer more fundamental questions about Grin’s governance, as in how decisions are made, who has authority to make these, and what the path is for a community member who would like to take on greater responsibilities.

This is a proposal to evolve our governance process.

Objectives

  • Reward and recognize contributions better. Offer different ways to become more engaged and give better recognition for work
  • Empower more to contribute. Encourage more community members to participate, facilitate more initiative.
  • Make Grin less centralized. Rather than relying on a small group of people, share responsibilities and make the project more resilient against shocks.
  • Create a more transparent process.

Not objectives

  • Do not create fiefdoms. Do not create emperors. Nobody is anybody else’s boss.
  • Do not create bureaucracy for the sake of bureaucracy. Do not impose death by a thousand papercuts or let forms and administration get in the way of making progress.
  • Do not discourage contributions. Nobody can prevent someone else from doing work. Anyone can contribute in which ever way they find meaningful. You do not need to ask for permission.

Proposal

This proposal outlines a set of loose principles to guide the work we do. While some of these may already be in use, they might not have been articulated before. It converts the council into a core team, and outlines its responsibilities for the first time. In addition, it’s proposed that additional teams are introduced alongside it, as well as an RFC process. An initial teams breakdown is suggested, and the proposal concludes with a path to adoption.

General principles

  • Lead by example. “Cypherpunks write code.” We don’t tell others what to do. We do what we can, and if we need to we ask for help. We suggest, but never command. We act as we want others to act.
  • Not a democracy. We are evaluated based on the work we do. It’s not a popularity contest, and the majority is not always right. Community members are here by their free will, participation is optional.
  • Influence is measured by recent and not historical work. We are grateful for and respect historical contributions, but they do not lead to lifelong positions of authority. Influence is earned by making contributions consistently over time, allowing new contributors to join the ranks of the old.
  • Transparency. Where possible, discussions and decisions are made in the open. We have nothing to hide, and we do not try to limit oversight unless there’s a defensible reason to do so.
  • Keep things lightweight. We strive to only put in place the minimal structure and organization that’s needed, neither more nor less.
  • Groups organize themselves. Structures do not need to be imposed tops down, and we recognise that what works for one group will not necessarily work for the other. Teams self-organize and define their own workflows and processes as they see fit.
  • Consensus-seeking decision making. Voting creates winners and losers, and is polarizing. We recognize there are trade offs with everything and rarely any single right answer. This does not mean design by committee. We seek consensus through dialogue and discussion, but where there is a lack of consensus, we do not let it block us indefinitely. We’re ready to make judgment calls to the best of our abilities.
  • We speak for ourselves. We can only speak in the name of ourselves, as contributors to the project. We do not write blog posts, articles, tweets, or give interviews speaking on behalf of the project as a whole. Grin itself has no single voice.
  • There’s no need to ask for permission. We are not afraid to take decisions. We ask for feedback and opinions from others, but we do not need to ask for somebody’s permission. If we believe it’s in the best interest of Grin, we act, and are accountable for our actions.
  • Mistakes are tolerated. As with any organization structure, mistakes happen. This is understood, and mistakes are accepted. We try to learn from them and improve. We assume we all act in good faith, until proven otherwise.

Core team

The existing grin council is proposed to be renamed to core team. The core team leads the wider Grin project as a whole. In particular:

  • Sets overall direction and vision. Core values and philosophies. Steering towards use cases and targets.
  • Sets priorities and plans releases. Maintains high level planning, roadmaps, focus areas, decides on pace and the release schedule.
  • Work on broader, cross-sectional issues. What falls in-between sub-teams, taking a global view.
  • Adds and removes sub-teams. While proposals for new sub-teams can come from anywhere, the core team is responsible to ensure structures are productive and make sense.
  • Responsible for security. Handles disclosures, vulnerabilities, audits, processes.
  • Handles multi-sig keys and takes high level spending decisions. Spending proposals can be made by anyone, and sub-teams can have their own own budgets to deal with as they please.

The core-team is self-selecting, and may include sub-team members. Over time, it’s intended to be a broad representation of the wider community with diverse stakeholders.

RFC process

An RFC is a Request For Comments document, outlining a proposed improvement or design change to an area of Grin. The exact specifics for the template is TBD. They are kept in their own dedicated repo and need to be accepted before a pull request is merged. Their purpose is to outline a standardized way of making proposals and allow the community to discuss and evaluate whether something is worth doing. Having an RFC accepted means that there’s support “in theory” for the suggestion. It does not mean that a change becomes implemented automatically or in the exact way it is proposed, it is high-level design. The work still needs to be carried out. Accepted RFCs guide the broader planning work.

Sub-teams

Sub teams are groups organized around specific areas or knowledge fields. They are responsible for these areas, but do not do all the work. Anyone can contribute anywhere, and do not need to hold a particular title to do so.

Rather, sub-teams work on policies, processes, and workflows for their specific areas, as required. They are in charge of the RFC process in their specific field: They determine what requires an RFC in their area, they assign RFC shepherds that guide an RFC through its various stages and ensures the right stakeholders become aware of it and solicit their feedback. Ultimately, sub-teams decide whether an RFC in their area should be accepted or rejected. They are responsible to ensure that each RFC in their area has a tracked status, and that they progress towards an outcome.

Sub-teams self-organize. They should have a leader, often this leader may be part of the core team. They determine how members get added to the team. They should include area experts, and stakeholders.

Sub-teams can be broken down into smaller working groups or sub-teams, permanent or temporary, as required and is seen necessary for them to be productive.

Each sub-team has a dedicated section on the forum, they should meet regularly, and keep some notes on what was covered and decided. Decisions do not need to happen in meetings, and could for example be handled asynchronously or in the RFC process.

The teams

In addition to Core team, the following teams are proposed to be created initially.

  • Node development. Core Grin technology, changes and optimizations to the node and anything consensus related, research and discussion of new technologies, proof of work.

  • Wallet development. wallet technology, wallet API, wallet-related research.

  • Infrastructure. Technical documentation, non-technical documentation, QA, testing, toolchain, developer productivity, guides, how-tos.

  • Ecosystem. 3rd party developers interaction (wallets, pools, exchanges and others), integration and technical assistance, growing the grin ecosystem, stakeholder collaboration.

  • Community. Onboarding of new community members, website, chat channels, conferences, events, meetups.

  • Fundraising. Sponsorships, donations, activities to increase project funds.

  • Moderation. Code of conduct, handles violations, across all areas of the project. To avoid biases and conflicts of interest, this sub-team does not contain any member of the core team.

Adoption path

  1. Publish proposal on grin-forum.org, refine as required
  2. Discuss in governance meeting, refine as required
  3. If approved;
    • Sub-teams:
      1. Appoint team leads from council/core where available
      2. Let sub-teams without leaders self-form once there is someone ready to step up
    • RFC process:
      1. Propose template & process document
      2. Create repo

References

Rust’s governance process

Node.js governance

Swarmwise, by Rick Falkvinge

21 Likes
2

I propose a Keybase team. If you haven’t heard of Keybase - definitely worth checking out. Their team/chat functionality rivals Slack, except it’s free. Keybase itself is rooted in cryptography.

I have a heavy background in Systems Infrastructure & Administration. I would love to be a part of the Infrastructure/Website/Ecosystem teams, or a mixture. I have many years experience in design & implementation of systems, as well as integration. Combined with a customer-service-focused mentality and strong inductive reasoning skills, I believe I could assist Grin. I’ve owned several businesses and am strong in building brand recognition as well. I can assist anywhere from hardware to software, networking to security, servers to desktops. Details gladly provided upon request.

Feel free to message me here or via Keybase (encrypted).

grin-forum.org does not resolve… there is no DNS record for it.

4 Likes
3

There is a Keybase team already - see https://keybase.io/team/grincoin

3 Likes
4

Well I guess I’m late to the party :blush:

2 Likes
5

Just for the record, personally I’m completely on board with this proposal, which is the result of a few weeks of internal discussions among the current council. I really very much urge everyone to read this carefully, reflect, and comment as this is arguably the most important change to Grin anyone has proposed to date.

3 Likes
6

The Grin Council… err the Grin Core Team has shown their good intentions and morality numerous times, and this is simply the next logical step. Big kudos to you for coming up with that proposal!

If this were a democracy, I’d vote “yes!”

5 Likes
7

@lehnberg your proposal looks great and seems to be a solid next step. I’m looking forward to hearing more community feedback. I initially wanted to generally ask if it makes sense to include security solely in the core team responsibilities. Instead I ended up with a proposal for a security subteam as an alternative option. I’d be grateful for any feedback and encourage any discussion for why they think a security subteam would be an asset or a liability.

Grin Governance Iteration Modification Proposal: Add Security Subteam
tl;dr

  • Modify Grin Governance Iteration to include a Security subteam
  • Reduce administrative overhead and centralization/liability risk for core team handling all aspects of security
  • Empower core team to more efficiently address security with their direction and vision
  • Improve transparency, accountability and reaction time for security practices and processes for Grin

Motivation
Background
Currently the governance iteration proposal puts the responsibility of handling disclosures, vulnerabilities, audits, processes solely on the core team.

The core team may not be now (or may not be in the future) sufficiently supported with the processes and experiences to proactively manage the mentioned security aspects while still maintaining focus on other duties.

Example: security review status indicated https://github.com/mimblewimble/grin-pm/blob/master/notes/20190611-meeting-development.md

The culture of security for a project like Grin is important for its long term survival and should be set up in a way that is not weakened with the comings and goings of core team members with varying security priorities and experiences.

A subteam can be suitable to support the technical and administrative overhead necessary for maintaining a long term and proactive security culture in the Grin ecosystem.

Objectives

  • Cultivate community contributions in security by offering ways to recognize contributions with active engagement and feedback
  • Empower the community to take their own security seriously with proactiveness and transparency
  • Reduce centralization and other failure risks for handling vulnerabilities
  • Improve overall transparency around security processes for the Grin project and ecosystem

Not Objectives

  • Do not add friction or confusion to the existing vulnerability disclosure system
  • Do not compromise the trust of the community

Proposal
This proposal outlines the general responsibilities and roles for a security subteam for Grin as well as the advantages and risks.

Responsibilities

  • Formalize and facilitate responsible disclosure processes (incl. on-call management, disclosure key schemes etc)
  • Curate and publish disclosed and fixed vulnerability reports according to the formalized disclosure process
  • Design, deploy and maintain bug bounty program
  • Manage RFC process for security related policies, processes and workflows
  • Manage future audits with team and community feedback through RFC process
  • Advocate for and engage in fundraising for future security audits
  • Continually assess and address attack vectors on codebase, networks and overall ecosystem
  • Coordinate and maintain emergency upgrade network to deploy fixes in cases of severe vulnerabilities
  • Maintain coordinator channel for responsibly disclosing vulnerabilities and fixes to forks and other related implementations
  • Assist other teams and ecosystem members with scheduled hardforks to encourage secure network upgrades
  • Regularly update community with indications of progression in quantum ability
  • Engage with community regularly about security related topics in the grin ecosystem (talks, articles etc)
  • Provide representation for dev/community meetings
  • Monthly reports: internally for core/subteams + publicly for community

Roles
At minimum a core representative and dedicated security lead would be required.

The security lead is there to support the direction, vision and priorities of the core team with protocols, procedures and advice.

Eventually a subteam PM could be added to free more time for the security lead to grow the subteam toward reducing reliance on the security lead (assuming the community feels the subteam is adding enough value to grow)

Advantages

  • Frees up core developer time from tedious but necessarily timely administrative tasks
  • Provides a holistic approach to security for the Grin ecosystem
  • Better prepares the ecosystem to be proactive and reactive to security emergencies
  • Encourages a long term culture of security for the project
  • Reduces liability for core team

Risks

  • More cooks in the security kitchen (in some circumstances it can be more efficient and secure for a small core team to be solely responsible)
  • Increased overhead of dedicated team members
  • More complex than directly mailing a core developer in case of vulnerability
  • Offsets trust of vulnerability disclosure from core devs directly to a protocol and potentially differently trusted community members (I think this is what lehnberg’s proposal is going for in general and is good, but for something like vuln disclosure for ecosystems like this it is critical to get right)
  • Potentially redirects focus from other important areas (“if it ain’t broke…”)

Future Work
Provide formalized proposals for community consideration for:

  • vulnerability disclosure process and protocol
  • bug bounty program structure
  • evaluation of existing security process
  • subteam budget
  • subteam responsibilities and roles assignments

About Me
I got involved with BTC in 2012 and was motivated by exploring new tools to preserve and protect digital rights. My first work in the space was contributing to the world’s first scrypt asics in 2013-2014. After that I contributed to various privacy preserving and AI/ML projects until 2017 when I co-founded a blockchain security solutions company. There I helped build the world’s first quantum resistant signature scheme deployed to a public blockchain mainnet and facilitated security audits and engagements for many projects ranging from pure crypto to legacy dinosaurs. In Dec’18-Jan’19 I was able to help facilitate a very quick audit of Grin’s crypto library and gave a short talk on it at grinconus.

Currently I am exploring new models for providing sustainability, accessibility and capability to privacy preserving projects. I feel that this is an interesting opportunity to apply my experience and ultimately make progress toward the end of ensuring future generations have the choice of privacy. My intention with this proposal is to improve the security culture for Grin and by extension improve the sustainability, accessibility and capability for all decentralized privacy preserving projects.

Next Steps
If there is initial interest, we could add a discussion point to the Governance meeting agenda for June 18. If this proposal gains further support I would complete the items in the future work section and iterate on them until the community is satisfied to build out the subteam. I would assume responsibility for this following the adoption path in the original proposal for at least 3 months as a contribution to the Grin ecosystem.

If the community finds that it does not make sense to have a dedicated security subteam my hope is that through the discovery process the existing process ends up more robust and transparent.

Thanks for reading and participating in Grin’s governance. I’m looking forward to answering questions and discussing Grin’s security culture.

4 Likes
8

Grin is an amazing project, and there are amazing people here, without understatement, especially the Core Developers and early github Contributors.

There are very few such people, so I formulated my sentences to increase the participants. Common people need more motivation and that’s my proposals:

  1. People who are willing to be motivated only by pure interest, involvement in the project for a goodwill to all humanity, are so rare. Even more rare those who are ready to do it full time. Project need to be upgraded by the motivations of Grin owning. And the Core Team and General Fund need to be leaders in this movement.

  2. The project grows, new branches appear, donations come to the project, they will be even much more, when the donors see, that the funds are being spent very efficiently. While I do not see this, I am saying it frankly. I had an experience with charity programs, Grin need much more transparency in this case. Transparency and efficiency are the 2 key indicators, that can improve donations much higher.

  3. The Grin Technocratic Council or Core Team, as perfectly noted in the proposal, should form the tasks and the long-term agenda. The Core Team also needs :

  • To form tasks and assign rewards for them from receiving funds (donations, payments, etc.).
  • The participants of the teams (there may be a lot of them) see the tasks and the proposed reward, the whole reward is only nominated in Grins, all funds in other currencies are transformed into Grin. In an auction format, groups offer their conditions for the implementation of tasks and deadlines. They put offers down from initial reward.
  • Grin General Fund accepts proposals from teams for the implementation of tasks, upon implementation the members of General Fund collectively accept the work and send an award.
    -.In this payment format, it is possible both project tasks and periodic payments to the Core Developers and teams. Also i think ,that the members of the Core Team and the Grin General Fund also must be rewarded.
    -. Since the reward will be in Grin, and the majority of participants are confident in the success of Grin the cost of work in FIAT or Bitcoin will be higher than in Grin.

  1. It is important that the Grin General Fund has an optimal number of participants, ideally 5 people, to minimize bureaucracy and represent the community.

  2. Fund reports must be no less than 1 time per month, and preferably at each Grin General Fund meeting ideally all movements are publicly available online (in the same Google Doc for a start) everything should be very transparent and so not needed to wait a long time for reports and results. Online fund movements is perfect.

About me:
my name is Alex, I am from Russia, my skills - sales and promotion , lawyer, crypto and blockchain enthusiast. Now I’m doing as much as I can to promote Grin in the Russian-speaking crypto community - website, groups, increasing the population of Grinners.

1 Like
9

Fantastic effort and achievement by the core team / council to get such a novel and exciting project to this stage with Trojan work done and funds raised transparently with no obvious nefarious activities extant to date. FWIW, I think the aims of this governance iteration, encouraging more participation, RFC process and less centralization in principle sound good but as an interested observer I think there are ambiguities in this manifesto, despite the admirable desire for egalitarianism and transparency. I would respectfully suggest that a couple of things may benefit from clarification, particularly:

  • We speak for ourselves. We can only speak in the name of ourselves, as contributors to the project. We do not write blog posts, articles, tweets, or give interviews speaking on behalf of the project as a whole. Grin itself has no single voice.

This strikes me as excessively idealistic and also counter-productive; it seems to be assuming that the best of all possible worlds will emerge without any guidance but rather a reliance on good actors to get on board and do the right thing at all possible junctures. It sounds like wishful thinking and could open the project to charlatans, profiteers and pirates of all descriptions who have various self-serving agendas that are not aligned, with the result that progress could be severely restricted due to infighting, dispute resolution, rogue forks, wasted effort, yada yada… Why not at least have a rotating committee of “core team” appointed rep.s that can give the odd interview, write a blog etc to communicate the core vision? Unless there is no core vision and it’s all just some sort of crypto-Darwinian experiment(?)

Also:

  • And There’s no need to ask for permission. We are not afraid to take decisions. We ask for feedback and opinions from others, but we do not need to ask for somebody’s permission. If we believe it’s in the best interest of Grin, we act, and are accountable for our actions.

I don’t think it’s clear – at least not to me – if you are referring solely to just the new “core team” or the core team and the various subgroups that may or may not be formed(?) If the former, it sounds like the Grin Council has just been renamed, whereas if the latter, it sounds like a recipe for chaos. I think the council has done an excellent job to date and without some central oversight, the project could lose its coherence in short order. Similarly to previous point, I see dangers in the council relinquishing so much ownership (as opposed to control). If it ain’t broke why “fix” it? Sometimes someone needs to take charge – it’s not necessarily evil… ; )

P.S. Maybe other interested parties/lurkers would be more inclined to respond to this proposal (and contribute to the project in general cf. subgroups) if the rationale for this proposed changes were elucidated a little more and who the “we” is in the above excerpts – while there is obviously a lot of good will for the project as well as $$$ already invested, I’m not sure that it will be totally clear to Joe Grin what is not currently working. My 2 milligrins’ worth.

2 Likes
10

Please keep the name grin council you amazing wizards! :dog:

1 Like
11

I approve of the governance proposal, and my response is based on the structure and recommendations it includes.

I apologize if this is redundant or obvious.

As a comnunity member, I support this proposal as-is for the initial governance next step.

I recommend and suoport that either the council or the core team delegate to a small group (I recommend exactly 3) the folliwing tasks:

  1. Define and publish first revision of RFC process. Call it RFC #0.

  2. Draft and shepheard (sponsor?) RFC #1 to implement the governance proposal here, using the RFC #0 process (which, of course, would bring in wider participarion via whatever means are defined in RFC #0).

All other suggestions, related or unrelated may progress forward here in the forum until RFC #s 0 and 1 are adopted, and subsequently flow through the RFC process.

I further recommend that the adoption of RFC #0 be time-boxed to prevent possible delays from any attempt to create the perfect RFC #0.

I have significant trust in the current leadership/council as evidenced by their achievements thus far.

I believe the open RFC process/concept has perhaps the best track record for ensuring that open distributed systems retain a steady and healthy emergent growth and evolution.

Respectfully,
-james aka qxotk aka condios luz verde

1 Like
12

I’ve collected all of the docs and outstanding questions into the fledgling Grin RFC repository with draft RFCs filled out for all of the above governance and RFC process topics. Would appreciate if we could all move the discussion there to help hammer them home!

13

not sure link works, maybe

14

rogue comma, should work now

15

I approve of the governance proposal, and my response is based on the structure and recommendations it includes.
重庆欢乐生肖, 彩票开奖
I apologize if this is redundant or obvious.

As a comnunity member, I support this proposal as-is for the initial governance next step.

I recommend and suoport that either the council or the core team delegate to a small group (I recommend exactly 3) the folliwing tasks:

  1. Define and publish first revision of RFC process. Call it RFC #0.
  2. Draft and shepheard (sponsor?) RFC #1 to implement the governance proposal here, using the RFC #0 process (which, of course, would bring in wider participarion via whatever means are defined in RFC #0).

All other suggestions, related or unrelated may progress forward here in the forum until RFC #s 0 and 1 are adopted, and subsequently flow through the RFC process.

I further recommend that the adoption of RFC #0 be time-boxed to prevent possible delays from any attempt to create the perfect RFC #0.

I have significant trust in the current leadership/council as evidenced by their achi

16

Changing the name of the Technocratic Council to a name more fitting of a decentralized, community driven project is a top priority in my opinion. Indeed calling it the core team like Bitcoin is appropriate enough.

17

Very well articulated proposal @lehnberg. I’m in full support and keen to contribute in any non-technical capacity. This probably limits me to Community and Fundraising, possibly Ecosystem development. Happy to coorindate a London meetup in the Autumn.

Is the Wikipedia entry still required? I could make a start on that over the summer.

4 Likes
18

Thanks @DoctorStrange!

Yes, it most certainly is, see here: Add Grin wikipedia entry · Issue #92 · mimblewimble/grin-pm · GitHub

Feel free to take a stab, happy to help wherever I can!