Governance

Short Description	Decisionmaking process at neuromatch.social
Contributor(s)	Jonny Saunders
Approval Status	Approved
Completion Status	Ongoing
Loomio Thread(s)	https://loomio.neuromatch.social/d/N3JMkiod/-proposal-governance
Date Proposed	2023-01-30
Date Approved	2023-02-13
Topic(s)	Governance, Proposals, Discussions, Voting

Up to 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 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 category, which in turn has a page schema.

Bylaws

	Bylaw
Description	A basic operating principle of neuromatch.social. Should be general enough to allow refinement by policies.
Voting Period	14 Days2 Weeks <br />
Block Threshold	0.1

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

	Policy
Description	A collective decision that structures the operation of neuromatch.social. Must be consistent with any existing bylaws.
Voting Period	7 Days1 Weeks <br />
Block Threshold	0.2

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

	Norm
Description	Nonbinding statements about the way that things are usually done, or suggested behavior on neuromatch.social. Sometimes norms can be akin to guides. Norms are intended to be fluid and reflect the current practices of the membership. Norms are not intended to be logically complete or settled, and can contain multiple conflicting perspectives or variants.
Voting Period	3 Days0.429 Weeks <br />
Block Threshold	0.5

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:

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 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 policy, bylaw, norm, or approve some action like merging a hack, among others.
• Links to Context - Any links to preceding discussions or relevant examples

Loomio threads should

• Start with [Proposal]: (proposal title) 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 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 policy, it should have a wiki page with a filled policy template.
• Announce the result using the relevant 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 technical maintenance or moderation (eg. Mastodon/Mods On Call).

Bounded Discretion

See also: 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 social wg might be given discretion over "content moderation decisions consistent with the 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 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
• ICA Cooperative identity, values and principles

Governance
Part Of	Mastodon, Mastodon/Bootstrapping
Contributors	Jonny Saunders
Completion Status	In Progress
Active Status	Active
Approval Status	Provisional