Skip to main content

Governance Protocol

Samara decision making protocol

Proposal 0.1

 

 

  1. Aims of governance in a decentralised environment
    • 1. No participant, or group of participants should be able to dominate discussions or control decisions in a decentralised and distributed authority environment.
    • 2. This does not mean that all decisions need to be made by consensus, or that everyone will be happy with the decisions that are made,
      • 2.1. In practice all decisions by consensus and 100% of people happy with every decision would indicate a lack of diversity or potential innovation.
    • 3. The process should be fair, recorded and unbiased, while reflecting the value created and invested in Samara by each member.

 

  • 4. As much as possible, operational decisions should be made by the people or bodies with a direct connection to the decision.
    • 4.1. Person/s who will carry out or establish the measures made in a proposal if passed should be suggested in the proposal, so that the work involved and who could carry this out has been considered

 

  1. Types of proposals

 

  • 1. Proposals can come from individuals or groups

 

  • 1.1. Proposals coming from individuals

 

  • 1.1.1. Every Samara member can make a proposal. When possible, a proposal should seek advice from 3 other Samarians to refine it and give it the greatest chance of success before being brought to the attention of a wider audience.

 

  • 2. Proposals coming from pods/circles/working teams

 

  • 2.1. Pods/circles/working teams decide the method for making decisions within their group, as well as the way they want to record decisions made. It is recommended to record decisions in a distinct way. A few days, weeks or months after a decision it is easy to forget the sequence of events should a group find that there were mixed expectations or misunderstandings about a decision, which is bound to happen at some point during busy periods.

 

  • 2.2. For proposals that impact the entire organisation the recommendation is for pods/circles/working teams to use the consent process before going further with the proposal for the entire organisation to vote on. Pods/circles/working teams can decide to use another decision method if that works better for them in general or for a particular decision. Decisions related to the budget/financial use or control of Samara (expenditures, roles, internal quests, compensations for contributors or consultants etc.) are all considered to impact the entire organisation because they will use the shared budget. This can be reviewed should different budgets be established or discretionary spending by circles become useful at a later stage.

 

 

  1. Voting using Loomio

 

Loomio is excellent as both a polling and consent process container and gives clarity about decisions that have been made and how. The timeline is clear, all comments are recorded and even those that are deleted can be found by admins.

 

  • 1. Process :
    • 1.1. Proposals that impact more than one pod/circle or the entire organisation will go to Loomio and ask for a vote from all Samara contributors (Samara DHO Group).
    • 1.2. Note: Samara DHO Group is made of everyone who has contributed to Samara and has earned Samara Voice Tokens (1$ contribution = 1 Samara Voice Token)
    • 1.3. Decisions on Loomio can first be added as proposals for feedback if that seems to be useful for the person (group) making the proposal (no mandatory requirement, recommended for decisions that are riskier/irreversible).
    • 1.4. The decision method on Loomio is based on unity/quorum (80/50) - See definition below. Options for voting are Yes/No/Abstain. Voice computation is made in this spreadsheet after the vote period ends and the result is added to the Loomio thread. Walkthrough demonstration.
      • 1.4.1. The quorum number should drop as the organisation becomes bigger and higher levels become naturally more difficult or even inappropriate to maintain.
      • 1.4.2. This ensures that anyone can signal the need for a higher quorum equally, regardless of accrued voice.
      • 1.4.3. This in turn means that people with a higher voice are not able to maintain or vote a lower quorum in for advantage.
      • 1.4.4. *Note: This may seem unnecessary, but it is a useful protective mechanism considering we do not know what the future will bring. From an outside perspective this keeps those who contribute the most to Samara over time being justifiably blameless in the process of representing voice.

 

  • 1.5. The voting period for Loomio is set to 5 working days for standard decisions.
    For urgent and reversible decisions the minimum voting period is 2 working days.
  • 1.6. It is recommended to include the following details in all Loomio proposals wherever applicable:
  • Goal of the proposal.
    • This is important to check if the proposal has had the intended effect later on and for learning.
  • Type: Policy/Role/Circle (pod/working group)/Quest/Badge/Other
  • Permanence: is the proposal permanent? Is it reversible? Does it set a firm precedent?
  • Urgency:
  • Risk: Low/medium/high
  • Impact: individual/group/organisation. Unknown = probably high risk
  • KR(s) if applicable
  • Timeline - implementation period, review dates, v2.0 etc.
  • Resources required: financial/human/others
  • Responsible fellow/group
  • Group/pod/circle title - Loomio puts a name to every proposal, so if the proposal is being put up by a group this needs to be clear..
  • Pod/circle/working team consent: Yes/No/NA +any objections raised in the group.
  • Person/people who will carry out the measures or process identified in the proposal should it pass.

 

* Note that Loomio is being used for proposals that impact the entire organisation until Samara DHO platform is available.

 

 

Glossary of terms:

Unity/quorum 80/50: 80% unity - Yes votes represent min 80% of the total voice casted; 50% quorum - all votes cast (Yes/No/Abstain) must represent min 50% of total voice. This method ensures a significant minimum level of unity and minimum inclusion of voice without needing full consensus or being held up by those unable/not voting.
*Note: The quorum number should drop as the organisation becomes bigger and higher levels become harder to reach even with proportionally significant support. This will be embodied in future updated versions of this policy

 

Until Samara moves to the DHO system, if someone leaves the DHO, or is away for an extended time, they are not included in the quorum/unity calculation, so that necessary proposals are not blocked simply because some people are not around, have moved on or are on holiday. 

 

Consent: https://www.sociocracyforall.org/consent-decision-making/

 

Proposal: ‘offer’ ‘proposition’ ‘plan’ that establishes some precedent, new or adjusted boundaries, shifts fundamental definitions or commits Samara’s resources towards a particular direction.

 

Samara fellow/member: Anyone who has earned Samara tokens by contributing time, energy and most importantly value can vote. A ‘Samara fellow’ is the first member stage that earns voice tokens.

Back to top