Deciding How to Decide

When embarking on a governance transition, projects are often faced with an unexpected question.

Not "what is the new govenance structure going to be?" That's the expected question. But lurking beneath is another: "How do we decide?" And beneath that, another: "How do we decide how to decide?"

You could keep going! How do you decide how to decide how to decide?

It's a recursive question. And because of this recursive nature, we can never arrive at an "objectively correct" or "perfectly legitimate" answer. In his article All Foundings Are Forced, political science professor Arthur Applbaum concludes that there is no procedural way to garauntee legitimacy when starting something new.

However, just because we can't garauntee legitimacy doesn't mean we can't aim for it. We can create something that works on a practical level.

Applbaum writes:

There is no fundamental difference between a dozen persons in a state of nature consenting to start a revolution together and consenting to go to a movie together. Any such group agent is unstable and unenforceable, but factually possible to realize.

In other words, forget about pursuing legitimacy and think about what people in your community will accept as "good enough".

When figuring out a good enough way to "decide how to decide" there are three basic questions you need to answer.

Who is going to decide?

This is the most important question. Excluding stakeholders who want to participate in decision-making from the governance process is one of the most surefire ways of breeding resentment. Conversely, bringing in people who don't actually care can cause logistical problems or lead to rushed decisions.

If you have an existing body of people who represent the community's stakeholders well, you can just use that. When Guido van Rossum stepped down as BDFL of the Python programming language, he said it was up to the Python core developer team to decide what came next.

If you don't have an existing body, you can create a new one. When doing so, ask yourself two questions. First: who is already in the community and cares about the project? You can invite them to participate in the new process. Second: who is impacted by this project but not necessarily represented in the community? Is there a way to reach out and bring them in? For instance, maybe you want users represented in your governance, but don't have a lot of user participating in the community. If you can identify some of those users, you can invite them into the governance process.

Note that with a new group, there is likely less trust built up. If you're transitioning your governance, you might want to create the group, build trust, then formally hand over power. If you're in a rush, it's far easier to leverage existing bodies and relationships.

How are people going to decide?

The second most important question is how people are going to decide. We can break this down into two phases: the brainstorming or nomination phase, and the actual decision-making phase.

In the brainstorming phase, there's a tension between wanting to be expansive and allow people to share all of their ideas, and not overwhelming yourselves with the many different options. During Python's governance transition, people submitted different governance models to be critiqued and voted on. Conversely, as a consultant, one of the things I offer is to create a single governance proposal that the community can adapt and change as they see fit. Neither of these options is inherently better than the other. It depends on what you want to prioritize.

When it comes to the decision-making phase, one of the core questions to consider is how much consensus you need. In small enough groups, you may be able to say you need full unanimous consent, but for most groups, that's impractical. So...how much disagreement can your community stand? Do you want to require a 3/4 supermajority vote? A 2/3rds majority? A simple majority vote?

Rather than getting bogged down in the numbers, it's important to think about what those numbers represent. A vote where 10% disagree but they're chill about it is very different than a vote where 10% disagree but they're furious.

Thinking relationally, we need to create space for disagreement. We can do this in a few ways:

• surfacing disagreements and tensions in productive ways, rather than trying to ignore or avoid them so "we can get this done"
• validating the experiences and needs that lay behind the disagreements, and affirming our care for the people disagreeing
• putting good faith efforts into compromises, wherever possible
• making sure that your goverance is adaptable so that disagreement can be easily revisted

If you can do these things, I don't think it matters what your vote threshold is.

Finally, there's a logistical question implied in "how". Are people going to make these decisions in person? Over videocall? Asynchronously, via text?

Most communities opt for a mixed approach. It's hard to beat asynchronous processes for convenience and accessibility. Still, it's important to supplement these processes with some more personalized interactions. If it is possible to have at least one in-person meeting, I highly recommend it. Getting together in person is the best way to create te social bonds which are the glue of governance. It's also often easier to read and understand each other when face to face.

When are they going to decide?

The third and by far least important question is when are you going to decide. How much time are you going to give yourselves to debate options? How do you know when it's time to hold a vote?

Rather than picking a time frame like "three months from now" I encourage you to pick a condition. For example, "We will vote when two-thirds of people say they're ready to vote." "We will vote when there are no more unresolved amendments to the main proposal." This is not to say that deadlines are bad! If you do take the deadline approach, just make sure to think about whether the community is actually ready.

Summary

Again, here are the questions you want to answer;

• Who is going to decide?
  • Do you have an existing body of trusted community members you can leverage?
  • If you're making a new body:
    • Who is already active in the community?
    • What stakeholder groups would you like to see represented in the community?
• How are they going to decide?
  • How will a governance structure be proposed/nominated/created?
    • Do you want members to propose multiple options to choose between?
    • Do you want to work off a single proposal, and debate changes to it?
  • How will the governance structure be decided on?
    • How much consent do you need?
    • How will you address disagreement?
      • How can you surface disagreement?
      • How can you encourage people who disagree to share underlying hopes, fears, and needs?
      • How can you encourage compromise?
      • How can you ensure disagreement can be revisted later?
• When are you going to decide?
  • How much time do you have to spend on this? Are there any deadlines looming?
  • What conditions need to be met before a decision can happen?

I know it looks like a lot (and it is! that's why people hire governance consultants) but it all boils down to three questions: who, how, and when.

Good luck!