How we work!

Governance Model as defined by

DisCO Gov. Model

Our Version of the Disco

Decision Making Process

The bulk of the decisions affecting the day to day of the collective and its future are made by all committed members. Other decisions can be shared with the wider/casual community. Why this split? Core Members depend on the collective for their livelihood, so decisions or votes which could be subject to harm by individuals who are not affected by the health of the collective should not be delegated beyond the committed membrane. Examples of harm would be anything from well-meaning but ill-informed or ill-considered tangents, diversions. We don’t expect to face this in a trust-based group but, this would also be a defense against trolling. On the other hand, as the resilience of the committed team increases, more and more decisions could be made with participation within the casual sphere.

Our chosen tool for decision making is Loomio, which has all the features the collective needs (it fits like a glove with the original Open Enterprise Model) For anyone not familiar with Loomio, it is a decision making platform based on the logic of Occupy and other self-organized assemblies. There are various levels of privacy within Loomio Groups.

Within Loomio, the collective operates with a general policy of lazy majority. Lazy majority allows for consent-based decisions to be made without resorting to across the board consensus, and keeps the work agile and free from red tape. Loomio is also used for discussions and quick “temperature checks”. The ideal is to have dynamic communication that is conducive to concrete outcomes. This blog post perfectly illustrates how Loomio discussions can improve the health of a community, please read it. That being said, our community rhythms also specify that all members check in and take part in any Loomio votes (even as “undecided”) at least twice a week and continual lack of engagement in discussions and decisions will result in members reevaluating their relationship and commitment to the collective.

The Process

Decision making typically involves the following steps:

  • Context
  • Discussion
  • Vote
  • Decision

For this example we will be centering on the committed sphere where the Core Members group together.

Any Core Member can open any discussion with the community. In order to initiate a discussion about a new idea, they add the idea to the appropriate Loomio group This will prompt a review and discussion of the idea. The goal of this review and discussion is to gain approval for the proposal. The collective also has ongoing discussions in Loomio which are tied to specific tasks and projects.

Loomio allows for work-items and ideas to be voted upon by the community. However, different levels of voting and approval may be needed depending on the situation. In general, as long as nobody explicitly opposes a proposal, it is recognized as having the support of the community. This is called the lazy majority: those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal, and those that showed up to vote determine the direction of the work.

Lazy majority

Lazy majority is a process that allows a large group of people to efficiently reach consensus. As someone with nothing to add to a proposal affecting a work team they may not be involved and need not spend time stating their position, and others need not spend time reviewing it. This section describes how a vote is conducted. The following section discusses when a vote is needed.

For the lazy majority to be effective, it is necessary to allow at least 72 hours before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal. This time period is chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments. More complex proposals which may require more thinking/reading of materials etc, can be extended.

If a formal vote on a proposal is called, all Core Members can express an opinion and vote. Those still in the trial Phase are fully encouraged to vote and discuss, but their votes are not binding.

Types of votes

  • ‘agree’: agrees that the action should move forward
  • ‘disagree’: disagree but will not oppose the action
  • ‘block’: opposes the action, and must propose an alternative action to address the issue or a justification for not addressing the issue
  • ‘neutral’: indicates that attention has been given to the action but abstaining from voting one way or another

Another way to abstain from the vote is for participants to simply not participate. However, it is more helpful to cast a ‘neutral’ vote than to abstain, since this allows the team to gauge the general feeling of the community if the proposal should be controversial.

When a vote receives a ‘block’, it is the responsibility of the community as a whole to address the objection but it is expected that the “blocker” takes the lead by offering a (perhaps) better alternative taking everyone’s needs into account. Such discussion will continue until the objection is either rescinded, overruled (in the case of a non-binding block)[22] or the proposal itself is altered in order to achieve consensus (possibly by withdrawing it altogether). 

The collective can also make more informal decisions within the work teams by a quick text based “check-in” (For example, someone proposes something in Discord and all members of that work team give it a thumbs-up. If there’s no agreement or if the working circle recognizes that proposal as a larger issue, the discussion is transported to Loomio).

Voting summary:

  • Those who don’t agree with the proposal and feel it would be detrimental to the collective if pursued should vote ‘block’. However, they are expected to submit and defend a counter-proposal.
  • Those who don’t agree but don’t find it intolerably detrimental and don’t have a better idea should vote ‘disagree’. Then, if things go wrong down the line, they can say “I told you so!” (priceless).
  • Those who agree should vote ‘agree’.
  • Those who do not care either way or who find themselves on the fence should vote ‘neutral’.
  • Those who are on sabbatical or have communicated days off/holidays don’t need to vote at all, but they can chime in after the vote has closed. 

Type of approval

Different actions require different types of approval, which are summarized below. The next section describes which type of approval should be used in common situations.

Lazy majority: 72 hours

A lazy majority vote requires more binding ‘agree’ votes than binding ‘disagree’ votes and no vetoes (binding ‘block’ votes). Once 72 hours have passed, the decision moves in the direction of the majority. Naturally if an actual majority of members vote before the 72 hours are up, the decision moves in that direction immediately.

Sometimes a lazy majority is tied with a vote threshold. This allows for decisions to be made quicker than 72 hours if enough members vote. If the vote threshold is reached before the 72 hours are up, the decision moves in the direction of the majority.

Unanimous consensus: 120 hours

All of the binding votes that are cast are to be ‘agree’ and there can be no ‘disagree’ votes or vetoes (binding ‘block’ votes)

When is a vote required?

Every effort is made to allow the majority of decisions to be taken through lazy consensus. That is, simply stating one’s intentions is assumed to be enough to proceed, unless an objection is raised. Activities that require more control and should be recorded as part of the Open Coop’s collective history are taken through a lazy majority, which is still informal enough for the team to stay agile. Repeated/regular tasks are generally not subject to votes, they’re assumed to be “pre-approved” unless they need to be re-evaluated for whatever reason and, in that case, discussed and voted on. Our definition of “Lazy Consensus” includes acknowledgement (a “like” or neutral vote). We encourage extensive use of Loomio’s participatory facilitation features, as they help focus discussions and clarify ideas and feelings. Occasional lack of participation is tolerated but discouraged. Continued lack of participation may result in a graduated sanction.

However, some activities require other types of approval process in order to ensure the health and cohesiveness of the collective.

This section identifies which type of vote should be called for:

  • Regular work task: Decisions will be made on a decision by decision basis as defined by team. Some will be made by the work team leader, some by team members collectively, some by team members individually, polls can be used as needed, and anyone can block a decision as desired. In the event teams get stuck they can ask any core member outside the team for advice. Any commitments require the consent of the party being committed. 
  • New Transitional Member: Unanimous consensus of all Core Members (Applies to all the quarterly evaluations during trial phase)
  • New Core Member: Unanimous consensus of all Core Members (after 6 month trial period)
  • Core Member removal: Unanimous consensus all Core Members
  • Blocked discussion where no decision is made: Keep talking(revising) till a decision can be made
  • Blocked discussion where some element of constitution is violated: Kick it up to the Core Members
  • Structural Governance model change: Core Members + Advisory vote by Transitional
  • Legal structure changes: Core Members + Advisory vote by Transitional

Members key:  

  • Core: Primary members of the Coop
  • Transitional: Members moving from casual to core
  • Casual: Does work with the coop but is not a core member

Supporters: external to the coop

Organizational Structure

Worker Support Team

  • Team members take turns facilitating meetings
  • Members are all Core Members of the Disco + Transitional Members
  • Top level team in the organization
  • Make all decisions around organization structure and legal structure changes
  • Primary concern is organizational care work
  • Catch any work that falls through the cracks from other teams

Key practices
  • Regular meeting times 
  • Roadmap(s)
  • Note taking practices 
  • Set specific meeting type(s)

Work Teams

  • Has a specific domain and aim(s) given from the parent team
  • Work teams have at least one team lead
  • Team members take turns facilitating meetings
  • Does not overlap with another’s domain
  • Must have 2 members from the support team
  • Founding document
    • Domain
    • Aims
    • Goals
    • Roles
      • Leader
      • Scribe
      • Team care
    • Feedback questions/reflections
  • Can create sub team / squad / mini fam 
    • Has specific scope
    • Double links with parent work team 
      • Must have 2 members from the parent work team

Key practices
  • Regular meeting times 
  • Roadmap(s)
  • Note taking practices 
  • Set specific meeting type(s)

How we work together

  • Consensual agreement necessary for one team asking another team to do/help with something. 
  • Members of any team can reach out to another team for help with something they have domain over
    • Communication between teams should be encouraged
    • Each team can define its own procedures for handling requests for help from members of other teams
  • A vote of no confidence can be raised as a proposal in loomio with a vote to replace an existing team leader

More to come!

When it comes to building community or organization that people really want to be a part of it takes time and experimentation. We took a great template and are making it into something that we are really excited to participate in. We hope you stick around to see what we end up making and the amazing people that will make it with us.

Leave a Reply

Your email address will not be published. Required fields are marked *