Samara Governance

Samara decision making protocol

Proposal 0.1

Aims of governance in a decentralised environment

No participant, or group of participants should be able to dominate discussions or control decisions in a decentralised and distributed authority environment. That is why we avoid voting when possible for day-to-day low-risk decisions that affect groups, but use voting to make clear and formal decisions when they affect the direction of the organisation as a whole.This doesn’t mean that all decisions need to be made by consensus, or that everyone will be happy with the decisions that are made, because this would mean a lack of diversity or potential innovation. The process should be fair, recorded and unbiased, while reflecting the value created and invested in Samara by each member.

As much as possible, operational decisions should be made by the people or bodies with a direct connection to the decision. Person/s who will carry out or establish the measures made in a proposal if it passes should be suggested in the proposal, so that the work and responsibility it implies are explicitly considered and understood as much as possible.

Types of proposals

Proposals can come from individuals or groups

Proposals coming from individuals

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.

Proposals coming from pods/circles/working teams

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.

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.

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.

Process :

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).
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)
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).
The decision method on Loomio is based on unity/quorum (80/20) - 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 .
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.

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/20: 80% unity - Yes votes represent min 80% of the total voice casted; 20% quorum - all votes cast (Yes/No/Abstain) must represent min 20% of total voice. This method ensures a significant minimum level of unity and minimum inclusion of voice without needing consensus or being held up by those unable/not voting.

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.

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.