Openweb Governance Body

WIP Repo of the codebase, and instructions for easy installation and setup.

All the planning text and activity is in the wiki and issues.

What is the #OGB

The #OGB codebase is a set of software tools which encode a governance model based on traditional grassroots activism combined with experience gained of using the fediverse as a technological tool for the horizontal scaling of social power. It focuses on sortition and messy consensus to achieve decision making and power distribution.

An Open Governance Body (#OGB) - for which the codebase is named - is a decentralized and democratic system for "governance" of any collective/community of (generally speaking) Producers¹ and Consumers². Throughout this text we use the fediverse as the example.

For the fediverse, three groups - Stakeholders³, Users⁴, and Affiliate Stakeholders⁵ - are used to provide a balance of perspectives and interests, with Stakeholders being chosen from and representing the people running instances, Users representing the people using the instances, and Affiliate Stakeholders representing other coders, organizations and groups supporting the fediverse.

How it works

The specific process used to achieve outcomes is determined by the wider community and remains mutable. The job of the codebase is to provide the #KISS tools and variables that facilitate this process. The workings of an open governance body is meant to be messy. There are few set laws or statutes, but instead a growing body of mythos and traditions that people can build and reference when making decisions. To ensure accountability and maintain trust within the community the model includes the power of recall, which is enacted at any time, for any members of the Voices⁶, Groups⁷ and Body⁸.

The “Tyranny of Structurelessness” helps design democratic and effective decision-making structures. By delegating specific authority to Groups for specific tasks, requiring accountability and transparency, distributing authority among people, rotating tasks, allocating tasks based on rational criteria, and providing equal access to resources and information, the group can ensure that power is not concentrated in the hands of a few individuals or agendas. [link to our tickbox wiki page]

The system incorporates a “Security Group” to detect bad actors, and “recall” process to demote individuals who do not align with the goals of the community. The structure is designed to be flexible, where variables and options may be redefined to suit the specific needs of the community.

The codebase includes Templates⁹ for many different views of [#4opens](link first use) governance, for example with options to aid/onboard new Roles¹⁰ by having an overlap with the old roll-holder where they share the role during a transition. The size of the #OGB Body can be reduced to human levels by using sortition to limit the number of participants in any pools within the Party¹¹. For example within the fediverse use case, 100 Stakeholders and 100 Users. This would be matched by a smaller number of Affiliates, providing a balance of perspectives and interests. maybe link this as its complex

It should be noted that the idea of sortition and open governance is not new. It is a way of organising that has been used in ancient Greek city-states, modern courts and jury's and more recently by #XR to address the climate crises. It's implementation in our roll out example within the #Fediverse is a new and exciting way of building decentralized and democratic governance.

Consensus

This refers to a level of agreement or acceptance reached by a Group or community on a proposal or action. In our case it is not a specific process or method, but rather a general principle that guides decision-making within the Group. link

The #OGB has several mechanisms in place to mitigate the risks of capture by special interests or bad actors. By allowing all Members of the Body to participate in the formation of Groups and the formation of Agreements¹², the system is designed to reduce the power of "capture" by any one group or individual.

The Body, Voices and Groups

Groups are formed around issues that receive a level of support from Members¹³ of the Body. Agreements are reached through discussions and consensus-building within a Group.

Additionally, allowing Members who were not selected by the sortition to still submit proposals for Group decisions directly ensures the input and perspectives of all Members are considered.

Voices, which are a subset of Members, have the power to both initiate Groups and enact Agreements reached by Groups.

The number of Voices is dynamic and would depend on the size of the Pool(s)¹⁴, but a small number, such as 3-5, would be ideal to ensure that the system is nimble and responsive to the needs of the community.

The Affiliate Stakeholders would bring additional expertise and perspectives to the table and their membership application would have to be ratified by the Body to ensure that they align with the goals of the community.

Community and the tradition of recall and dilution

The Voices are representatives of the Body, but ultimately it is the Body who holds the power and makes the decisions. It is meant to be messy and not a traditional power structure, a “native” approach working within the decentralized and disorganized nature of the #openweb commons..

The Groups and Voices have the power to make decisions, but they need to work together to build consensus to make effective decisions. The model acknowledges the challenges of working in disorganized groups of individuals and the importance of building a body of mythos and traditions to guide decision-making over longer terms (even multi-generational).

The recall and dilution mechanisms provide a way for the community to self-regulate and course-correct when necessary. Voices have limited terms and are replaced by members the Body, so their power is not permanent.

Messiness

The proposed system embraces the messiness of real-world governance and is designed to work within it, rather than trying to impose specific ideas of order. It is built on the principle that power should be distributed horizontally and that decisions should be made through community wide consensus-building.

Issues

• Prioritization: The proposal system allows for prioritization by allowing the governing body to decide which proposals to take action on and which to ignore.

• Spam: The use of standard moderation tools and community flagging systems would help to address the issue of spam. add-link

• Centralization: The #OGB takes into account the potential for centralization and addresses it by encouraging participation and giving power to those who actively contribute to the community.

Fediverse use case

Our first focus while developing the #OGB is on the fediverse, where the OGB itself will be a citizen, though the principle and structure can and should be applied to any "producer" communities both on- and offline.

The governance body's for the fediverse will be "native", building on the same technology - effectively themselves instances within the fediverse - streaming data/comments in from other instances, with all activity, process, decisions and publications being posts back out into the fediverse.

Proposals come from anyone with an ActivityPub account, giving all interested users the opportunity to responsibly shape the direction of the fediverse. The consensus of Voices, minus one, is what turns a Agreement into "the voice of the instance", ensuring that the agreements reached by the Body are truly representative of the wider interests and agenda.

Based on the statistics of a population of over ten million accounts and more than nine thousand instances, it would be difficult for a Body of that size to make decisions efficiently. A smaller representative Body can be more focussed and better able to make decisions quickly and effectively. this is built into the codebase by both horizontally federating new instances or restricting the size of the body it self, both are good approaches.

The goal is to mediate the shifting of power from the .01% to the 99.9% of the fediverse. This codebase and approach is designed to scale horizontally for use in other grassroots "producer" democratic structures both online and offline, such as local street markets, a protest camp, eco villages.

There can (and should) be multiple #OGB's within the fediverse, that may grow, shrink and divide/merge organically over time. We are describing one example to provide a seed from which to grow. The output from one OGB federates to feed into another and back. This will be fully implemented as the design and codebase is refined after initial roll out.

Process

The model allows for any User to submit a Proposal, with subject tags which will be visible on the activity streams of the governing body. The Body can then decide to take action on the Proposal by passing it to an existing Group or forming a new one to work on it. Prioritization of proposals will be handled by the Body and the Groups, with spam being dealt with by flagging and standard moderation tools.

Additionally, the use of sortition and flagging mechanisms can help to ensure that the voices of the community are heard and that bad actors are held accountable. The use of sortition to select Voices, and the ability for other Body members to flag bad Voices, provides a way to detect and address any individuals or groups that may be acting against the best interests of the fediverse.

Basic security checks to detect sock puppets and spammers, and the ability to “recall” flagged accounts, helps to ensure that the governance body is representative. If people start to game the system, the solution is to get more people involved, which will dilute the problem. Sortition will shift bad groups out when fresh people of goodwill join.

to sum up, the system relies on a combination of automatic checks and human moderation to ensure accountability, while also recognizing the limitations of #tredtional formal non "native" processes and the importance of trust based collaboration. The emphasis is on keeping the system simple #KISS, flexible and adaptable to the needs and culture of the instance community. The use of human flagging is a core way to address potential abuse of the system, helping to ensure that larger and more influential instances do not dominate the decision-making process.

Why build a native approach?

The challenges of using formal processes - such as those used by #NGO's and cooperatives in #openweb and activism projects - are that they are rigid and not suited to the decentralized and dynamic nature of these communities, particularly the fediverse and activism. LINK

Existing projects and resources that may be relevant to governance such as Loomio, Decidim, and Sociocracy tend to be based on formal consensus, which as mentioned above, is a very bad fit for messy, unstructured groups.

The #OGB project is meant to reflect the practical, on-the-ground reality of horizontal activism and the #openweb fediverse culture. It is not based on idealistic or theoretical models, but on the lived experience of the community.

Make reality

It should be noted implementation will be complex, while the resulting tools should themselves be simple.

The development of the project will involve a production/coding team, funding, and testing with a real user base.

We want to see if there are individuals within the fediverse who have the skills and interest in helping to build the tools and processes needed for the project, and if so, to explore potential collaborations and partnerships.

We also want to raise awareness and focues on understanding of the project, the issues it addresses, and to gather feedback and input from a diverse group of people.

Summary

The proposed governance model is designed to be messy and non-hierarchical. It is meant to work with the fediverse's decentralized structure, and it is built on a long history of grassroots activism. It is not a traditional power structure, and it relies on consensus and recall processes rather than laws or statutes.

It's important to keep in mind that this system is built on trust and collaboration, and relies on the Stakeholders being engaged and willing to work together toward common goals.

The goal is to work with, not against, this history and avoid the pitfalls of “process geeks” coming in and damaging the movement, which is the normal outcome. We need to recognize that the need for control is often a barrier to finding solutions, and instead focus on building structures and tools that allow us to navigate the mess and make good decisions collectively. This can be achieved by building bridges and fostering communication between different perspectives, rather than trying to control the outcome. The key is to find a balance between different approaches and allow for diversity of tactics.

Definitions

The choice of terminology is non-trivial. Here are our working definitions of what we mean by certain key terms. These will change based on response and feedback from the living community. All of them will also likely be variables within the code, such that they may better reflect their function in a given use case "template".

---

1. A common pool within the Party. A Producer is meant to signify people who provide/do something. This could be a market stall community, teachers in a classroomor our working example, the fediverse instance admins/mods. ↩︎

2. A common pool within the Party. The people who support and use the products of the Producers. ↩︎

3. Synonym for Producer. Specific to the fediverse use case. A subset of the Party who are instance maintainers, admins and moderators. ↩︎

4. Synonym for Consumer. Specific to the fediverse use case. A subset of the Party who are the users of an instance. ↩︎

5. An example of something other than Producer or Consumer but who is still a fundamental part of the OGB's community. Specific to the fediverse use case. People who "work" to build the infrastructure of the instance subject path, such as programmers, organisations and groups supporting the fediverse. ↩︎

6. A subset of the body chosen by sortition, who accepts responsibility for getting stuff done. This is a very active role. They have a power to veto decisions made by the body, but by tradition should not use it with out good reason and strong trust/consensus building. ↩︎

7. A place to work though problems and come up with solution paths for the Body/community to make decisions about the path to recommend. These are different in that Groups are self-selecting and not filled via sortition; the checks and balances being provided by the sortaion of the Body and Voices. ↩︎

8. The governance body, picked by sortition form the pools of people who are interested and active. In the fediverse use case the pools would be Stakeholders, Affiliates and Users. ↩︎

9. A way of defining a work process; boiler plate text and names for the underlying codebase to display and use. To start with we will be focussing on 3 templates - spiky, which we know works, fluffy which will need more testing, and a balanced approach which should work fine. The template system can be used to define most democratic organising processes, once we have the code working well. There are also Body-wide decisions, which will likely be rare and or trivial, and the Party can add proposals but these would be advice only. ↩︎

10. A nebulous but needed term we are yet to define clearly, a "mini voice" within a Group. Likely not in v1 of the codebase. link ↩︎

11. Sum of the pools of Producer, Consumer and any other that may be specific to a given use case, defined by its template. Someone who walks the path, but does not yet help to produce/reproduce it. In the fediverse use case, this is everyone with an ActPub account who signs up to the OGB instance. ↩︎

12. These come from any part of the Body that have use of the voting/consensus tools to agree to a text that they have worked on together. Then implementation can be pushed by voices, groups and the body it self. ↩︎

13. An individual within the Body chosen by sortition from the pool(s) within the Party, to represent and deliberate the path. The Party were divided into subsets (pools), but here that distinction disappears and they are all just Members. ↩︎

14. A subset of individuals within the Party. The template in use by a given OGB will define these as necessary. ↩︎