Notes on IPFS Governance

This is not (yet) a governance proposal for IPFS; at this stage it is a set of notes and questions about how IPFS governance could work. The idea is to discuss and iterate, and to let some of these ideas marinate in the community for some time.

Basic Governance Structure

A plausible and pragmatic governance structure could look roughly like this:

• NomCom. A nomination committee is composed of all the people who have contributed to the community over the calendar year that precedes any action of the NomCom (typically an election). What counts as "contributing to the community" is something that should be subject to evolution over time, we have to make sure that it is properly inclusive. One kind of contribution is any substantial commit to any repo in, say, the ipfs or ipfs-shipyard orgs but we should ensure that we count things like organizing a conference or local event, writing documentation, cat herding, outreach. CoC violations can lead to exclusion from the NomCom.
• Technical Oversight. A small group of people elected by the NomCom who are tasked with the technical oversight of the IPFS project (managing IPIPs, setting roadmaps, coordinating test suites and specs…). This is similar to the Stewards today. We probably want to have limits on how many people there can have the same employer.
• Rules Group. A small group of people elected by the NomCom who are tasked with maintaining the governance system. Every system of rules needs a process to modify itself, which that group owns. They need to be in charge of the health of the IPFS project from a community and governance perspective.

Questions:

• How many people in each group?
• How do appeals work?
• How long are the terms and how are they staggered?
• How do we distinguish between small rule changes (that the rules group can just do) versus constitutional changes (that a wider group should vote on)?
• Who is in charge of transitioning to dogfooding?
• NomCom:
  • What gets someone included in NomCom?
  • What gets someone excluded from NomCom?
  • What is the process for considering that someone's contribution wasn't substantial enough (eg. a commit that just fixes a typo)?
  • What is the process for considering that someone's contribution was substantial even if it doesn't show up as something easy to count automatically?

Stakeholder Representation

One difficulty in setting up community governance is to avoid giving excessive power to a single group. Implementers have a lot of inherent power simply based on their control of infrastructure, and NomCom structured as above will easily consolidate that power. This can easily lead to toxic cultures in which implementers become gatekeepers for the entire community and believe themselves fair while in fact only listening to input that matches their biases. (This is the "call center" model of governance, in which the KPI is that implementers will consider themselves successful if they've listened to some people.)

Avoiding entrenched bias can only be achieved when decisionmakers are confronted with actual reality checks. (We can think of this as the scientific method for governance.) We should therefore look for ways to guarantee that a variety of stakeholders is represented, and can both collaborate and keep one another in check.

There are several ways to achieve that, depending on which stakeholders we wish to see represented. One is to divide the NomCom into constituencies and guarantee representation in each group for all constituencies. Each constituency could then have different rules for NomCom eligibility (eg. the implementers constituency might have commits, operators might have some measure of participation in BANANA, community leaders might have events organized). Another option is to reserve some seats for reps of other orgs. Say, hypothetically, a representative from the Content Addressable Alliance gets a seat and a vote. (How they pick that rep is up to them.) These options can be mixed.

A simpler mechanism will work better than a more complex one that tries to be scrupulously fair in excessive detail. The key questions are:

• Who should have voice?
• Who do we want backpressure from?

Rest of the World

We have a decent idea of how to build governance for a project the size and maturity of IPFS, even if it involves a number of open questions for fine-tuning.

What we don't know is how to avoid becoming insular, how to not develop a culture that is too weird and too detached from outside reality. Most governance groups of this nature develop exceedingly strong in-group mentalities. That makes for a powerful (and stimulating) driver of work while a project is still young and in need of adoption, but it cuts off participation from others and severely reduces diversity.

Ad Hoc Groups

People regularly need to spin up groups to coordinate doing things (not necessarily producing specs). We need a lightweight process to set these up (and spin them down), and some basic infrastructure to make them pleasant to work with.

tk

Specs Process

tk

• We need to enshrine IPIPs
• What else? Specs currently have more or less random maturity levels picked from a random set, how do we normalize that?
• How do we integrate with testing?
• What counts as wide horizontal review?

Capture Resistance and Scaling

tk

• There is a credible set of capture threats for which we need a good framework of vigiliance (making the Rules group in charge of this is a first step).
• How does this scale up
  $n$ orders of magnitude in money, deployment, etc.?

Foundational Values & Principles

tk

• How do we document the fundamental values of the project (what it's trying to achieve)? This is needed to support decisionmaking in the face of complex issues.
• How do we shepherd some essential docs: patent policy, license, copyright?
• What is the CoC?
• How do we handle CoC violations and appeals?
• Should these parts not be shared with a wider community of practice?

Funding

tk The Fund is a pretty important part of this; how do we enshrine and administer it? How do we encourage it to grow and get funders to contribute?

Questionnaire

tk

• What questions do we want to ask of people in order to refine this?
• Who do we want to ask?
• At the Thing meeting, the input we got was quite different from what we expected, we need to be careful about what we may miss.