Edit Policy: Governance

Warning: More than one default form is defined for this page.

You do not have permission to edit this page, for the following reason:

The action you have requested is limited to users in the group: Users.

:
Short Description: Short (1-2 sentence) description)	Decisionmaking process at neuromatch.social
Contributor(s):
Approval Status:
Completion Status:
Loomio Thread(s):
Date Proposed:
Date Approved:
Topic(s):

Free text:

Up to [[Part Of::Mastodon]] Neuromatch.social is a cooperatively governed instance that is operated with shared control over financial, labor, and structural decisions. Membership is not passive - members that make use of the instance are expected to make contributions to running the instance according to their ability and the need of the instance. == Overview == * Most of the everyday work of the instance is done by [[Mastodon/Working Groups|working groups]], but their structure and the rest of the operations of the instance are decided by the membership. * Changes to the instance are made with [[#Proposals]], which can be made by any member or working group * Proposals are typically preceded with [[#Discussions]], where a member consults a relevant working group or refines their language before proposing * Proposals follow some expected pattern of consensusmaking with a specific duration and threshold for consensus, depending on what type of proposal it is (see [[#Administrative Objects]]). == Administrative Objects == ''What kinds of things exist in the governance system of neuromatch.social'' See [[:Category:Administrative_Object]] The instance is governed by several different types of [[Administrative Objects]], each of which must have, and exists as a wiki page with a particular [[Special:Categories|category]], which in turn has a [[mediawikiwiki:Extension:PageSchemas|page schema]]<ref>ie. a [[Special:Templates|template]] that sets [[Special:Properties|properties]] and a [[Special:Forms|form]] for interacting with it</ref>. === [[Mastodon/Bylaws|Bylaws]] === {{#ask: [[:Category:Bylaw]] |? Has Description=Description |? Has Voting Period=Voting Period |? Has Block Threshold=Block Threshold |format=table |transpose=yes }} The bylaws determine the basic structure of the instance: what its purpose is, how it is to be run, and what its relationship is with its parent, [[Neuromatch]]. Bylaws require a higher vote threshold (or, fewer blocks are allowed) in order to change, since changes could dramatically change the instance. As a result they should be written generally enough to not micromanage the unpredictable policies that are needed to enact them. === Policies === {{#ask: [[:Category:Policy]] |? Has Description=Description |? Has Voting Period=Voting Period |? Has Block Threshold=Block Threshold |format=table |transpose=yes }} Policies operationalize the bylaws, and set core rules for how the instance is to be run. Policies should be consistent with bylaws. Members of the instance are expected to contribute to, know, and follow the policies. Each member is able to modify and create policies, so if they are missing or don't fit the needs of the membership, they should be changed :). === Norms === {{#ask: [[:Category:Norm]] |? Has Description=Description |? Has Voting Period=Voting Period |? Has Block Threshold=Block Threshold |format=table |transpose=yes }} Norms are useful for suggesting the "vibe" of the instance and supporting new members understand how things work. Norms offer suggested ways to do things, how members typically expect things to happen, and so depending on the content of the norm members might be encouraged, but are not required to abide by norms. Since each norm could have potentially multiple conflicting viewpoints, it is possible to approve multiple versions and amendments to norms without necessarily needing to make them consistent with previous norms. == Actions == ''What kind of things can be done by a member of neuromatch.social'' === Process === Rough outline: <graphviz format="svg" class="img-responsive" > digraph { ranksep=0.24 scale=0.25 // splines="ortho" // items // idea[ // label="Idea!!!", // shape=box3d // ] wgchat[ label="WG Discussion", shape=box3d ] loomio_disc[ label="Loomio Discussion", shape=box3d ] proposal[ label="Proposal", shape=box3d ] // decisions discussion_required[ label="Discussion\n Required?", style="dashed" ] iswg[ label="Related to\nWorking\nGroup?", style="dashed" ] // wg_discretion[ // label="Within\nDiscretion\nof Working\nGroup?", // style="dashed" // ] // passes[ // label="Proposal Passes?", // style="dashed" // ] iswg2[ label="Responsibility\nof Working\nGroup?" style="dashed" ] // outcomes wg_does[ label="Working Group Does It", style="filled, rounded", shape=box ] volunteers_do[ label="Volunteers Organize Labor", style="filled, rounded", shape=box ] // idea -> discussion_required discussion_required -> proposal[label=" No"] discussion_required -> iswg[label="Yes"] iswg -> wgchat[label="Yes"] iswg -> loomio_disc[label="No"] // wgchat -> wg_discretion wgchat -> loomio_disc wgchat -> wg_does[label="Within\nour\ndiscretion"] // wg_discretion -> wg_does[label="Yes"] // wg_discretion -> loomio_disc[label="No"] loomio_disc -> proposal[label="Refine Idea"] // proposal -> passes proposal -> iswg2 // passes -> iswg2[label="Yes"] // passes -> idea[label="Re-evaluate"] iswg2 -> wg_does[label="Yes"] iswg2 -> volunteers_do[label="No"] } </graphviz> Any member can make a '''proposal''' for the instance to take some action or change some structure. === Discussions === Proposals should start with a discussion. If there is a working group that should be directly involved with the idea, then discussions should start within working groups. Working groups, likely having some perspective on the idea, can help shape or refine the proposal, as well as offer any feedback it might need. If an idea is within the [[#Bounded Discretion]] of the working group, they might be able to just do it themselves. After any informal pre-discussion that might happen within the discord or working groups, the general membership is invited to a discussion that takes place in a [[Loomio]] thread. Within the discussion thread, the OP or any other participating member is encouraged to take interim polls to take the temperature of the instance or gauge quantities as relevant to the proposal. The OP might find it helpful to make an adjoining wiki page that has a [[Property:Approval Status]] of "Draft" in order to keep track of refinements to the proposal. Proposals do not **always** need to be led with discussions, and that is up to the discretion of the member (If future members have some problem with a member rushing things to proposals without discussion, they can propose to amend this policy <3). '''Reasons why a proposal might not need a discussion:''' * There is one unambiguous formulation of the proposal: "Defederate from instance X" * It's already been discussed informally with members of the relevant working group present * The proposal is pro-forma or otherwise very likely to be uncontroversial * ... === Proposals === ''See also: [[Making A Proposal]]'' Proposals should be made according to the schema currently in place for a [[:Category:Proposal]]. In general this should include: * '''Sponsor''' - If more people than the person posting the thread are involved in the proposal, they should be named * '''Cost''' - If a proposal is likely to cost something, the cost should be listed in the proposal ** The [[Mastodon/Financial WG|Financial WG]] should be able to provide guidance on the feasibility of any proposal given the current state of the [[Mastodon/Budget]]. ** If a proposal has some variable cost ("How much should we spend on x this month"), that is indication that a proposal needed further discussion, but it is always possible to propose the high-end of a cost range and use less than was proposed. * '''Specific Description''' - The description of what is being proposed, including any existing policies or etc. that will be changed. The content of a proposal is very general, as it is the basic unit of decisionmaking - a proposal can implement a new [[Mastodon/Policies|policy]], [[Mastodon/Bylaws|bylaw]], [[Mastodon/Norms|norm]], or approve some action like merging a [[Mastodon/Hacking|hack]], among others. * '''Links to Context''' - Any links to preceding discussions or relevant examples '''Loomio threads''' should * Start with <code>[Proposal]: (proposal title)</code> and be tagged as a Proposal * Tag any people or working groups that would be relevant to the discussion * Contain a poll that allows people to vote on the proposal (the type of poll will vary depending on the proposal) ** The poll should stay open at least as long as the relevant [[Property:Voting Period|voting period]] ** A thread can contain multiple polls if there are multiple independent components of a proposal. Polls should be split at the discretion of the proposer, but other members might ask to split a proposal to eg. avoid a block. === After A Proposal === * Update any relevant wiki pages ** If the proposal created or modified a [[Policies|policy]], it should have a wiki page with a filled [[Template:Policy|policy template]]. * Announce the result using the relevant [[Special Accounts|special account]], if one exists. * If a proposal requires a member or working group to take some specific action, distribute that labor accordingly === Emergency Proposal === When a member or WG needs to do something for a time-sensitive reason, eg. in [[Conflict Resolution]], the object of a proposal is only available for a limited time, an "emergency" proposal can be made. This is typically when a member doesn't feel like they have the consent of the instance to take unilateral action, but otherwise wants some input from the general membership. An emergency proposal can bypass the typical timeframes used for voting, but requires an additional proposal to be sustained after the fact. An emergency proposal should * be made with the "emergency" tag * describes the reason for urgency * tag any members of relevant working groups If after the emergency period passes, the subsequent proposal fails, then the OP is responsible for undoing the actions in the emergency proposal, if possible. == Working Groups == Working groups are intended to balance the need for all-member consensus with the need to keep the instance running day to day. Working groups have '''responsibilities''' and accompanying '''bounded discretion''' to meet those responsibilities. Conversely, in order to exercise the power implied by the discretion of a working group, a member should take some part in the work of the group's responsibilities: if one wants to second guess the work of a working group, a member should either be doing some of that work, or else be willing to describe how that work should be done differently as part of a structured proposal. Working groups should be established by a proposal that defines each of these three components: * How it decides its membership or decides who gets any sort of privileged access or power * What specific responsibilities the group has * What the bounds on its discretionary activity are === Membership === Membership in any working group should be fluid: in most cases, a member needs only volunteer for a working group in order to be considered a part of it. By volunteering to be a part of a working group, a member agrees to undertake some proportion of the WG's responsibilities, depending on the WG's operating practices. === Responsibilities === Instance membership determines the responsibilities of a given working group, and the working group is responsible for maintaining the documentation for how to meet those responsibilities. If additional responsibilities are requested from the membership, the membership should accompany those responsibilities with additional volunteer labor or additional discretionary power, depending on the circumstance. Each working group should maintain a list of responsibilities on its wiki page, and make it clear to the general membership who is to be contacted for any "On-Call" or ongoing activities like [[Mastodon/Tech WG|technical maintenance]] or [[Mastodon/Moderation|moderation]] (eg. [[Mastodon/Mods On Call]]). === Bounded Discretion === See also: [[Depends On::Access Policy]] Working groups should be given broad discretion to do the work needed to fulfill their assigned responsibilities, and so in addition to their responsibilities they should be designated a certain bound of discretion within which to operate under. This is by necessity ill-defined, and so should err on the side of generality: for example the [[Mastodon/Social WG|social wg]] might be given discretion over "content moderation decisions consistent with the [[Mastodon/Code of Conduct|code of conduct]]" and then be able to set their own processes within that. When the bounds to discretion become unclear, eg. the decision to defederate from an instance that many current members interact with regularly, the working group should take steps to informally or formally poll the general membership before taking those actions. When a member is unsatisfied with the work of a working group, they are welcome to join the working group and contribute to it, make proposals to change the operation of a working group, or enter into a [[Conflict Resolution]] process with its members. === Compensation === [[Mastodon/TODO]] - We should compensate working group members. This is left undefined at the time of proposal, but should be revisited later == Voting == ''See also: [[Consensus]]'' Neuromatch.social decisions are made with a modified form of consensus for large asynchronous groups. There is no minimum vote required for quorum: all members are encouraged to vote in all decisions, but since it is impossible to define how many members are active, there is no sensible threshold that can be set. Voting in a [[Consensus]] system is not like voting in a majoritarian system: * Rather than voting for the thing that would be best for you, you are voting for what is best for the instance. * Rather than the proposal being the starting point of a decision which then takes effect if a majority approve, the proposal is the endpoint in a process where the membership will have negotiated and discussed the form of the proposal and tried to address all needs beforehand. * Rather than voting "no," we think in terms of '''"blocking"''' a proposal: decisions should be made with the rough consensus of the whole instance, which is why the thresholds for approval are much lower than 50%. In smaller settings, a proposal can be blocked by a single person. The purpose for thinking in terms of consensus and blocking rather than majoritarian voting is to prevent a tyranny of the majority that might overlook the needs of marginalized or other groups in a numerical minority. In order to prevent every decision from devolving into an academic deadlock: * Members should be able to influence the particular structure of a proposal prior to a vote, rather than deliberate its details in the voting process. One should only "block" a proposal a few times during their tenure in a governance body, and any block should be an indication that the process has failed, rather than the proposal has failed. * Members that block should - with some exceptions like blocking an action that would be personally harmful to you - participate in the followup process to meet the needs that the OP was trying to meet with their proposal: blocking means you should take on work. * Members should resist the urge to micromanage and leave the granularity of decisions to the people that will be doing the work implied by any given proposal. We should cultivate a culture of trust in one another: believe your fellow members know what they're doing, and if you have input, you should be ready to volunteer alongside them. === Thresholds === Each type of [[#Actions|Action]] has its own threshold for consensus that must be met in order to pass. Consensus thresholds are higher than a simple majority to encourage all members to work together to structure policies that work for the entire instance. If a proposal's poll(s) pass the relevant approval threshold, then the policy or action described by the proposal === Non-Binary Decisions === If a proposal needs to make a decision that isn't a yes or no decision, then the following poll types can be used in loomio: * Ranked Choice - for deciding among an array of possible options * Score poll - for deciding on a continuous value like eg. a consensus threshold In this case, the poll should be accompanied by a second that allows members to block the proposal. Otherwise, the winner of the ranked choice or score poll is the result of the proposal. == See also == * [[Mastodon/Policies]] * [[Mastodon/Norms]] * [[Consensus]] * [https://www.ica.coop/en/whats-co-op/co-operative-identity-values-principles ICA Cooperative identity, values and principles] {{Project |Part Of=Mastodon, Mastodon/Bootstrapping |Contributors=Jonny Saunders |Completion Status=In Progress |Active Status=Active |Approval Status=Provisional }} [[Category:Mastodon]] [[Category:Governance]] [[Category:Project]] [[Category:Policy]]

Summary:

Cancel