Update 'README.md'
parent
f11553689c
commit
a1190b824a
185
README.md
185
README.md
|
@ -1,186 +1,153 @@
|
|||
# Openweb Governance Body
|
||||
|
||||
Currently all activity is in the wiki.
|
||||
**WIP** Repo of the codebase, and instructions for easy installation and setup.
|
||||
|
||||
The repo shall eventually hold the codebase and instructions for easy installation and setup.
|
||||
All the planning text and activity is in the wiki and issues.
|
||||
|
||||
---
|
||||
|
||||
WIP
|
||||
|
||||
---
|
||||
|
||||
## What is the #OGB
|
||||
|
||||
The proposed governance model is based on a combination of traditional grassroots activism along with the experience from the fediverse of federation as a tool for horizontal scaling of social power. It focuses on "[sortition]"() and “core consent” as means to achieve decision making and power distribution, and utilizes the concepts of “The Body”, “The Groups”, and “The Voices” to facilitate the process.
|
||||
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.
|
||||
|
||||
The specific process used to achieve core consent will be determined by the group or community using the tools and variables provided by the codebase.
|
||||
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[^producer] and Consumers[^consumer]. Throughout this text we use the [fediverse](link) as the example.
|
||||
|
||||
The vision of openweb governance is meant to be messy.
|
||||
There are no set laws or statutes, but instead a growing body of mythos and traditions that people can reference when making decisions.
|
||||
To ensure accountability and maintain trust within the community the model includes the power of recall, which may be enacted at any time, for both “The Voices” and “The Body”.
|
||||
For the fediverse, three groups - Stakeholders[^stakeholder], Users[^user], and Affiliate Stakeholders[^affiliate] - 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.
|
||||
|
||||
The structure is designed to be flexible, where variables and options may be redefined to suit the specific needs of the community.
|
||||
## How it works
|
||||
|
||||
The system incorporates principles, such as the use of sortition to select stakeholders, users, and affiliate stakeholders, the use of a “Security Group” to detect bad actors, and “recall” process to remove individuals who do not align with the goals of the fediverse.
|
||||
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](link) 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[^voice], Groups[^group] and Body[^body].
|
||||
|
||||
The system includes an option to aid/onboard new roles by having an overlap with the old roll-holder where they share the role and the use of tradition and workflow to mediate the “Allocation of tasks along rational criteria”.
|
||||
The “[Tyranny of Structurelessness](#link-here)” 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]
|
||||
|
||||
“Tyranny of Structurelessness,” helps designing democratic and effective decision-making structures. By delegating specific authority to specific individuals for specific tasks, requiring accountability, distributing authority among as many people as possible, 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 #OGB
|
||||
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 #OGB achieves this by limiting the number of stakeholders and users by lottery, for example, 100 stakeholders and 100 users. This would be matched by a smaller number of affiliate, providing a balance of perspectives and interests.
|
||||
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 governance that has been used in some ancient Greek city-states and it’s been proposed in modern times as well. However, it’s implementation in the #Fediverse could be a new and exciting way of ensuring decentralized and democratic governance.
|
||||
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.
|
||||
|
||||
### Core consent
|
||||
### Consensus
|
||||
|
||||
This refers to a level of agreement or acceptance reached by a group or community on a particular proposal or action. It is not a specific process or method, but rather a general principle that guides decision-making within the group. In the context of The Body, it may be achieved through a variety of methods such as voting, threshold, or other forms of consensus-building.
|
||||
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]
|
||||
|
||||
[MESSY addition, needs rewording:] The codebase will do it's utmost to provide tools that support this, with flexibility and "herding cats" being the guiding stars along with ease of use and comprehension, while avoiding being dogmatic or hierarchical - we must not provide tools that can be abused.]
|
||||
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 #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 dilute the power of any one group or individual.
|
||||
|
||||
The use of sortition to select users to be part of the Body would ensure a random and representative sample of the user base. And the dynamic balance of Stakeholders and Users would provide a check on the power of any one group.
|
||||
[PUT image in here]
|
||||
|
||||
### The Body, Voices and Groups
|
||||
|
||||
For a given OGB community, the Body is the core representative of the whole populace, but does not consist of the whole populace [CORRECT?].
|
||||
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.
|
||||
|
||||
The Voices are a subset of the Body, their chosen representatives at a given moment in time. How they are chosen is key and covered later.
|
||||
The lifespan of the Voices is flexible; by default this may be 1 year or a rolling 6 month term.
|
||||
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.
|
||||
|
||||
Groups are formed around a specific proposal and are thus inherently temporary events, living only as long as the proposal itself.
|
||||
Members of “Groups” come from “The Body” and [may/will?] include the original author[(s)?] of a proposal.
|
||||
Voices, which are a subset of Members, have the power to both initiate Groups and enact Agreements reached by Groups.
|
||||
|
||||
It’s important to note that the number of members in the Body can change depending on the situation. The admin group should be able to adjust the pool size depending on the requirement to try different approaches to see what works.
|
||||
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.
|
||||
|
||||
[Stakeholders?]
|
||||
|
||||
Groups are formed around issues that receive a level of support from members of the body, agreements are reached through group discussions and consensus-building. Voices, which are a subset of stakeholders, have the power to both initiate groups and enact agreements reached by groups.
|
||||
|
||||
Additionally, allowing stakeholders who were not selected by the lottery to still submit proposals for group decisions would ensure that the input and perspectives of all stakeholders are considered.
|
||||
|
||||
The number of voices is dynamic and would depend on the number of stakeholders, 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 members would have to be ratified by the Body to ensure that they align with the goals 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 a delicate balance that is built on trust and tradition, and it is meant to be messy and not a traditional power structure. It is a “native” approach that is designed to work within the decentralized and disorganized nature of the fediverse community.
|
||||
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 and make effective decisions. The model also acknowledges the challenges of dealing with a disorganized group of individuals and the importance of building a body of mythos and traditions to guide decision-making over longer terms (multi-generational).
|
||||
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 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 towards a common goal. The lack of a formal sense-checking [CORRECTION: Is this meant to be "consensus"?] step is intended to encourage decentralized decision-making and empower individuals and groups to take ownership of their own actions and decisions.
|
||||
|
||||
The recall and dilution mechanisms provide a way for the community to self-regulate and course-correct if necessary.
|
||||
Voices have limited terms and are replaced by members the Body, so their power is not permanent. Additionally, the Groups and other Voices [COORECT? That Voices help check the power of Voices] serve as checks and balances on the power of the Voices. This is built into the governance model to ensure that power is distributed and not concentrated in one group or individual.
|
||||
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 a false sense of order. It is built on the principle that power should be distributed horizontally and that decisions should be made through consensus-building and compromise.
|
||||
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.
|
||||
- Spam: The use of standard moderation tools and community flagging systems would help to address the issue of spam. [LINK]
|
||||
|
||||
- Centralization: The proposed system takes into account the potential for centralization and addresses it by encouraging participation and giving power to those who actively contribute to the community.
|
||||
- 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
|
||||
|
||||
[ADDITION; REWORD:]
|
||||
Our main focus while developing the OGB is on the fediverse, where the OGB itself will be a citizen - though the principle and structure could and should be applied to communities within and without the fediverse, both on- and offline.
|
||||
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.
|
||||
|
||||
[ADDITION; REWORD:]
|
||||
The governing body for the fediverse would itself be built on the same technology - effectively itself another instance within the fediverse, streaming data in from other instances, with all activity, process, decicions and publications being posts back out into the fediverse.
|
||||
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.
|
||||
|
||||
An Open Governance Body #OGB, would be a decentralized and democratic system for governing the fediverse. The three groups of stakeholders, users, and affiliate stakeholders would provide a balance of perspectives and interests, with stakeholders representing the people running instances, users representing the people using the instances, and affiliate stakeholders representing other organizations and groups within 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
|
||||
|
||||
The process would involve a lottery system for selecting members, with checks for instance activity and human involvement.
|
||||
Based on the statistics of a population of over ten million accounts and more than 9,000 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.
|
||||
|
||||
Based on the statistics of a population of over ten million accounts and more than 9,000 instances, it would be difficult for a body of that size to make decisions efficiently. A smaller representative body would be more manageable and better able to make decisions quickly and effectively.
|
||||
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, a producer Eqo villages
|
||||
|
||||
The goal is to mediate the shifting of power from the .01% to the 99.9% of the fediverse, and the approach is designed to scale horizontally for use in other democratic structures such as local street markets. The body would be moderated through flagging and standard fediverse moderation tools.
|
||||
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, its a native project (this will be fully implement in V02)
|
||||
|
||||
The lottery system would also help to distribute power more evenly among instances, as it would ensure that smaller and less popular instances have an equal chance of having a representative chosen.
|
||||
|
||||
The power of the voice in this proposed #OGB system is distributed among different groups and individuals. Proposals come from anyone with an ActivityPub account, giving all users the opportunity to shape the direction of the fediverse.
|
||||
### Process
|
||||
|
||||
The consensus of voices, minus one, is what makes an agreement the “voice of the Fediverse” ensuring that the agreements reached by the body are truly representative of the fediverse as a whole.
|
||||
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.
|
||||
|
||||
The workflow described is a way to ensure that the #OGB is a representative of the fediverse as a whole, by giving all users the opportunity to participate in the decision-making process.
|
||||
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.
|
||||
|
||||
By allowing users to opt-in to becoming stakeholders, and then using sortition to select a representative sample of users to serve as members of the Body, the system would be designed to ensure that the voices of all members of the fediverse are heard.
|
||||
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.
|
||||
|
||||
Additionally, the use of human flagging as a way to address potential abuse of the system would also help to ensure that larger and more influential instances do not dominate the decision-making process.
|
||||
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.
|
||||
|
||||
The system would rely on a combination of automatic checks and human moderation to ensure fairness and accountability, while also recognizing the limitations of formal processes and the importance of trust and collaboration. The emphasis is on keeping the system simple, flexible and adaptable to the unique needs and culture of the fediverse community.
|
||||
|
||||
The proposed #OGB aims to distribute power among as many people as possible within the fediverse, by delegating specific tasks and responsibilities to individuals selected through democratic procedures, with the goal of preventing monopoly of power and promoting decision-making through consultation.
|
||||
### Why build a native approach?
|
||||
|
||||
The proposed representative body for the fediverse would be a democratic structure that allows for the delegation of specific authority to specific individuals for specific tasks through democratic procedures. The Body would be composed of Stakeholders (instances/instance operators), users, and affiliates [SHOULD users and affiliates be inside the parentheses alongside instances?], with a focus on distribution of authority among many people and rotation of tasks among individuals.
|
||||
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]
|
||||
|
||||
The model allows for any user to submit a proposal which will be visible on the activity stream of the governing body. The body can then decide to take action on the proposal by passing it to a group or forming a new group 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.
|
||||
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.
|
||||
|
||||
It is important to note that the #OGB is designed to distribute power and decision-making among a diverse group of stakeholders, including instances, users, and affiliates. This can help to mitigate the risk of any one group or individual having too much power and influence over the fediverse.
|
||||
|
||||
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.
|
||||
|
||||
Additionally, the use of 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.
|
||||
|
||||
[SHOULD this be part of the fediverse use case, or the general?]
|
||||
If people start to game the system, the solution is to get more people involved, which will dilute the problem. The lottery will shift bad groups out if fresh people of goodwill join. If a user has multiple accounts, it is up to them to resign some of them, so new stakeholders can be chosen.
|
||||
|
||||
However, this will be up to the [~~group~~community?], as it is tradition. The default will be set, but it’s open to change.
|
||||
|
||||
The #OGB system will allow multiple accounts from a single user to be included in the lottery for selection of representatives for the Body (OGB), as long as they are active and human. The idea is to keep the system simple and easy to code by relying on flagging for blatant abuse, rather than hard-coding restrictions.
|
||||
|
||||
When an instance registers, it would appear on the OGB’s activity feed, giving members time to flag or discuss it if needed. Overall, it is important to keep the system as simple as possible and easy to code.
|
||||
|
||||
The key idea is to empower instances to decide who speaks on their behalf, and to moderate as much power downwards[outwards?] to federate responsibility.
|
||||
|
||||
The proposed system includes automatic checks, such as whether the instance is online and has been used recently, and whether single-user instances should be counted. There would also be an option for user/stakeholder flagging to question if an instance belongs, based on terms of service.
|
||||
|
||||
The challenges of using formal processes - such as those used by #NGO‘s and cooperatives, in #openweb and activism projects - are that they tend to be too rigid and not suited to the decentralized and dynamic nature of these communities, particularly the fediverse and acitivism.
|
||||
|
||||
Existing projects and resources that may be relevant to governance such as Loomio, Decidim, Noisebridge, and Sociocracy tend to be based on formal consensus, which as mentioned above, is simply a 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
|
||||
|
||||
However, it should be noted implementation will be complex #OGB.
|
||||
It should be noted implementation will be complex, while the resulting tools should themselves be simple.
|
||||
|
||||
The development of the project would involve a production/coding team, funding, and testing with a real user base.
|
||||
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 here who have the skills and interest in helping to build the tools and processes needed for the #OGB project, and if so, to explore potential collaborations and partnerships.
|
||||
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 understanding of the project and the issues it addresses, and to gather feedback and input from a diverse group of people.
|
||||
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.
|
||||
|
||||
[CHANGED THE FOLLOWING A LOT: Please correct for clarity and intention]
|
||||
Ultimately, our personal goal is to bring together a group to build this #OGB; and subsequently for it to be used on all scales, from smaller - e.g. our sister #OMN project as well as a diversity of groups, organizations and communities - through to the larger - e.g. the fediverse, perhaps villages, towns, ...?
|
||||
|
||||
### Summary
|
||||
|
||||
The governance model being proposed is based on a long history of grassroots activism and federation as a tool for horizontal scaling of social power. The approach focuses on sortition and taking power out of “power politics” by creating a modern take on classic social movement practices. The goal is to work with, not against, this history and avoid the pitfalls of “process geeks” coming in and damaging the movement.
|
||||
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 is important to understand that whatever process or governance structure is used, it needs to work in the messy reality of human interactions. 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 decisions collectively.
|
||||
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.
|
||||
|
||||
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 in different situations.
|
||||
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.
|
||||
|
||||
It is a way to empower the community and decentralize power, giving a voice to those who actively contribute and care for the fediverse. By keeping the system simple and easy to understand, it allows for more participation and creativity from users, rather than relying on a small group of individuals or organizations to make decisions. The focus is on the collective and community-driven decision making, rather than hierarchy and bureaucracy #OGB
|
||||
### Definitions
|
||||
|
||||
The goal should be to create a system that is inclusive and that promotes participation, rather than one that is complex and exclusionary. The key is to strike a balance between simplicity and effectiveness, and to focus on the overall goal of empowering the community to govern itself.
|
||||
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".
|
||||
|
||||
It is important to keep the #OGB governance system simple and easy to understand for all Stakeholders, as this allows for more participation and engagement. The focus should be on empowering the users and creating a decentralized system that allows for more voices to be heard and for the community to self-govern.
|
||||
[^body]: 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.
|
||||
|
||||
The approach is to empower people to take ownership of their governance, rather than providing them with pre-determined solutions. The goal is to create a flexible, adaptable system that can be adapted to the specific needs of different communities and organizations. Trust and collaboration are key elements, as well as a willingness to experiment and iterate. Overall, the main emphasis is on building a governance system that is grounded in the culture and realities of the community it serves.
|
||||
[^voice]: 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.
|
||||
|
||||
The #OGB project is meant to reflect the practical, on-the-ground reality of horizontal activism and the fediverse culture. It is not based on idealistic or theoretical models, but on the lived experience of the community.
|
||||
[^party]: 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.
|
||||
|
||||
[^pool]: A subset of individuals within the Party. The template in use by a given OGB will define these as necessary.
|
||||
|
||||
[^group]: 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.
|
||||
|
||||
[^member]: 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.
|
||||
|
||||
[^producer]: 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.
|
||||
|
||||
[^consumer]: A common pool within the Party. The people who support and use the products of the Producers.
|
||||
|
||||
[^stakeholder]: Synonym for Producer. Specific to the fediverse use case. A subset of the Party who are instance maintainers, admins and moderators.
|
||||
|
||||
[^user]: Synonym for Consumer. Specific to the fediverse use case. A subset of the Party who are the users of an instance.
|
||||
|
||||
[^affiliate]: 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.
|
||||
|
||||
[^role]: 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]
|
||||
|
||||
[^template]: is a way of defining work process and boler plate text, names for the underlighing codebse to dispay and use, to start with we will be focuesing on 3 templates spiky, which we know works, fluffy witch will need more testing and a balenced aproch which should work fine. the templating syteam can be used to define most democratic organising process when we have the code working well. The are also body wide desions, which will likely be rare and or trival, and partys can add propesals but these are advicey only.
|
||||
|
||||
[^agreement]: come from any part of the body that can use on of the voteing/consesus tools to agre to a text they have worked on togther, then implemention can be pushed by the voices, the best outcome, one voice withch is fine or a member of the group that created it, less usefull.
|
Loading…
Reference in New Issue