Samara Policies

How-to Guides

How-to Guides

How policies are written

Writing policies is a difficult task, they cannot be too specific or too broad, must be consistent and  clear, and enforceable in some way.  Not everything warrants a policy, in fact the less policies you have the better. The best policies are valid for a long period of time and need little to no amendments. It is always good to start with the purpose of the policy (why), followed by possible implementation paths (how) and examples of how it will affect the organization (what). Pictured below is the Golden Circle from Simon Sinek. For a more formal approach to writing policies, check out this document. 

image-1619321559166.png

https://eregs.github.io/guidelines/ 

How-to Guides

How policies are decided

  1. The new policy is drafted in this book (create new page and assign a sponsor)
  2. The new policy is discussed and refined (allow editing and keep revisions)
  3. The Samara organization is voting on the policy
    1. Freeze editing and set status  (admin only)
    2. Loomio vote (link to the policy page) OR
    3. DHO 90/30 vote (when available)
  4. When passed, the policy is enacted
    1. Change status to passed and add date
    2. Assemble team and timeline to execute policy
  5. When updated, the policy is amended
    1. Freeze is lifted (admin only)
    2. Note is added for amendment
    3. Make edits (try to do in one session)
    4. Policy is voted on again (#3)
    5. Link to revision page is added 

Samara Policies

Samara Policies

What policies are needed

(note: this is an initial stab at a list, by far not complete)

Finance & Payroll Policies

  1. Payroll & compensation (tokens & formulas)
  2. Funding & allocating (investors & tokens)
  3. Genesis contributions (value & voice)
  4. Treasury (redemption & accounting)

Governance Policies

  1. Badge multipliers (skills & achievements)
  2. Membership criteria (level & voice)
  3. Decision methods (quorum & unity)
  4. Circles in Samara (creating and formalizing circles) 

DHO Policies

Note: this is how future policies are configured in the DHO, with

# value or ## name-value pair, % percentage, ? toggle yes-no, & document, @ section

  1. Activities/RNA (assignments, contributions, quests, #length-trial, #length-regular)
  2. Organization/DNA (##tokens, %token-decay, ##composite salary, ##complexity bands, &policies, &circles, &role-archetypes, &badge-archetypes, &org-archetypes, @accounting, @treasury)
  3. Voting Methods (%quorum, %unity, #length, ?blocking, ?5-scale, ?dynamic quorum,  ?accelerated voting, ?high pass filter)
  4. Voice (%voice-decay, ?voice-delegation, ?account or token-based) 
  5. Brand (#color schema, &logo, &identity)
  6. Communications (?on-chain or off-chain)

 

Samara Policies

Compensation Model

Roz: Bring Samara-ness into it.
Find something that feels abundant. Bio-memetic.

 

Historical Context 

So far, Samara only dealt with a single type of compensation, called contribution:

In addition, Samara has developed an interim compensation model: clarify interim?  in between quests? in between funding? Simply "now"? If latter, perhaps add an "as of _______ date" to clarify? in between roles (long-term fin flows)

I think there should also be a low HUSD reserve model / clauses as well as interim. It's all very well defining HUSD needs in advance if there are sufficient reserves to be paying whatever people request. If reserves are low I would think it makes sense to temporarily limit the maximum amount, rather than % that each person can request based on a conservative estimate of when further HUSD will arrive. It doesn't makes sense for the org to simply hand out all HUSD reserves while they are there at the same time as making intelligent decisions about what is best for the org.

Policy Purpose (Why)

  1. to simplify and improve the above interim model
  2. to anchor the compensation model on the approach outlined in The Chronicles of Samara  and
  3. to better integrate 4 key components of compensation:
    1. Mindshare (how much of your life you give to Samara)
    2. Complexity (the anticipated intensity or difficulty of the work you do for Samara)
    3. Value (the actual value your contribution brings to the organization)
    4. Bonus (the go-above-and-beyond recognition as a generic multiplier added on top)

    To simplify the above interim model, we need to reconsider:

    To integrate the 4 key components, we need to revisit the compensation model and start at the bottom:

    1. Dividing mindshare into quests, contributions and roles
    2. Encoding complexity a priori through the allocation of the funding, expenses and salaries
    3. Decoding value a posteriori through the contribution level, proof of work and role archetypes (+OKRs)
    4. Adding a bonus through the membership level and badge archetypes

    Note that complexity is tied to a role-assignment within the context of a circle (e.g. a senior front-end developer for the DHO sub-circle in Hypha) and the value is decoded and voted on in an organizational context. 

    Implementation (How)

    Let's try to spell out a possible new approach for Samara:

    is there text that's coming here? seems implementation should come towards the end after we understand what the policy is. yes, didn't get to this yet

    Goals (TBD)

    Key principles (TBD)

    Band Definitions

    Universal, Consistent & committed ‘Work/Play-Pay’ (B1) 
    Mid Complexity Pay (B2):
    Max Complexity/Intensity Pay (B3):

    Compensation models 

    Seems 1 & 2 are coincident possibilities people can choose for a specific context, whereas 3 is for a different context. Am I correct? if so, would be good to explain this more. Irina: Yes, tried to explain below with an update. Feel free to change to make it clear.

    Joachim: I would not call them models, more like a design philosophy? Other than that compensation is either fixed (based on role commitment and complexity) or variable (based on contribution and co-eval) Irina: Alternative to models? I just put options for now until we come up with something better. Not sure if and how we would like to continue with the variable compensation (based on the co-ev) after we start going into long term role assignments. How about you break it down into 3 horizons: short, mid and long-term, with horizon 1 covering immediate needs for some members (as we did), horizon 2 beginning the transition and understanding the tokens we'll use and horizon 3 assuming a more stable org with circles and roles. +1 framing and making 3 time horizon designs/proposals makes sense to me. At the moment I see them clashing in the thinking here. I feel we need to separate them so short term considerations are dealt with clearly but are not interfering with longer term goal of ongoing policy.

    Compensation options in Samara are currently designed based on two different contexts:

    1. Periods of Official Samara quests (such as quests to Hypha or other entities providing quest-specific funding), when the following compensation options are available:

    A. Standard abundance compensation, Samara token as compensation. Permanently available for Samara members.

    B. Diverse compensation, a model that includes other available tokens in the compensation when these tokens are available (like for example HUSD, Liquid Seeds etc.). This model is available whenever Samara has a diversity of tokens and Samara members decide to use those tokens as part of compensating member's contributions.

    This model will be updated at the beginning of each quest period or whenever necessary, reflecting the available tokens.

    2. Periods in between Official Samara quests and before Samara enters into steady operations after the acquisition of substantial funding (definition of 'Steady Operations' and 'Substantial' TBD)

    A. Default model for in between Official Samara quests. The purpose of this model is to continue supporting the long term Samara contributors with the fiat needed to cover life expenses while being able to continue to contribute to Samara.

    Applicable to members with at least 3 months of past contributions at a commitment higher than 70%.

    Note 1: Before engaging with a quest or a role assignment with Samara, members provide information for the minimum amount of HUSD (fiat) needs they require in order to have a long term engagement with Samara at the desired commitment level. Not sure what 'initial request' means. what is that? when was it? Irina: tried to add more details, better?

    Note 2: For the period between quests starting with April 20, 2021 (not having a long history of past contributions behind) this model is applicable for past contributions higher than 50% in the 2 previous distinct evaluated periods (March 1 - March 12 and March 13 - April 19).

    Examples (What)

    1. Jeff joins Samara as a new member and goes on an onboarding quest
    2. After completion, he earns an Apprentice badge, some SVOICE and is looking for a long-term engagement
    3. The XYZ circle has a new job posting at complexity level "B3" and archetype "building"
    4. Jeff applies and is accepted into the new role and starts his new assignment
    5. Each week month he claims to pre-defined tokens for the B3-Builder role 
    6. At the end of each quarter (or 3 months period) he documents progress in OKRs

     

    1 This differs from the book, I believe Samara investors want to have a voice in decisions, that's why they invest, but that voice is lower than that for existing members enacting roles

    Irina: I have some concerns of giving voice to investors. Let's discuss.

    Bongi: +1 re: voice to investors. This is very related to our identity and values and think this should go to a vote on Loomio after discussion.

     

     

    Samara Policies

    Circles Budgets - draft

    Circle Budgets - draft

    (this is from Joachim reflecting the Hypha circle budgeting process which will be mapped to the DHO functionality later)

    Living Budgets

    Hypha has adopted a strategy of Living budgets that adapts to the environment and allows changes to the organism in near real-time. These living and breathing membranes provide the foundation for healthy competition amongst circles and roles in pursuit of purpose - rewarding successes and thriving organs and removing stagnation and parasitic behavior. There are two types of budgetary boundaries depicted below - (1) organizational budgets (funds available in the treasury, shown in grey) and (2) circle budgets (funds available in the circle, shown in black). Both boundaries need to be negotiated within the organism as a whole (sensing into the wants and needs or its members) and revisited on a regular basis. 

    image-1620934869867.png

    Budgets set natural boundaries to growth or detox. Circles gain and maintain a budget by how well they’re executing and providing value to the whole. This requires some signal to show what value was added and prevents members from overextending work ("I get paid by the hour") and from wasting resources ("we needed to justify our budget"). The organization can decide how these boundaries are enforced - either by defining a hard ceiling ("sorry, we are out of budget for this contribution") or a soft ceiling ("you are stepping over the budget boundary with this assignment, please reconsider"). In a near real-time scenario, these boundaries can be adjusted within the circle (reduce and increase activities) or across circles (reduce and increase spending).

    image-1620935380344.png

     

    Budgeting Process

    The budgeting process breaks down into two parts: 

    1. Overall allocation of funds routed to anchor circles (after deliberation and vote)
    2. Specific allocation of funds within circles and sub-circles (within circle autonomy)

    In the depiction below for the overall allocation of funds, we have three anchor circles receiving 50%, 30% and 20% of the overall budget of the organization. Initial budgeting figures can be created by 

    1. Creating an initial pro-forma budget sheet with monthly estimates for all expenses [1] 
    2. Doing a co-evaluation (via contribution accounting) to finalize the circle allocations [1]

    Note that after the initial budgets have been completed, the resulting distributions can be used to plug into the co-evaluation process and are no longer needed. 

    image-1620935626313.png

    In the depiction below for the specific allocation of funds within circles, we see the largest circle dividing funds among two roles, one taking about 55%, the other 45% of the circle budget. Note that there should always be a "buffer" for unforeseen expenses or additional contributions. Also note that there is an "anchor budget" as a catchall for roles that are not assigned to any circle.

     

    image-1620936009340.png

     

    [1] The Hypha Circle Budgeting Sheet

    Samara Policies

    Governance Protocol

    Samara decision making protocol

    Proposal 0.1

    1. Aims of governance in a decentralized 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 organization 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.

    Samara Policies

    Policy for creating Circles within Samara and for proposing role-assignments, quests and contributions

    EXPLANATION - Why this policy

    We need organizational protocols for complexity to turn into emergence.

     

     

    In order for birds to murmur (fly together in harmony), they don't just do whatever they want whenever the feeling strikes in isolation. They all play by the same rules and the same sensitivity to each other's position. They move according to the same biological/evolutionary responses towards the natural inputs they are sensing. Doesn’t mean each bird can’t still be unique or have unique relationships in the murmur, but there are commonly shared protocols. 

     

    For more details check out this short video by Tyler: https://www.loom.com/share/ebe90b744b8044caabe277464f1a08b6 

     

    In order to manifest the collective ambitions we have and keep our organisation supporting all its members on all levels, various circles form to see to different needs, tasks and initiatives. 

     

    This policy describes how Samara members can form a circle, balancing change and consistency in order to contribute and evolve.

     

     

    PROTOCOL

     

    1. How to start and formalize a circle

     

    Samara members who would like to start a circle create an Circle Outline Proposal with the following minimum amount of information:

     

    A Circle in Samara can be proposed by a minimum of 2 members. 

     

    When the outline is ready,those making the proposal add it to Loomio in a new thread for feedback and advice. After feedback, members create a poll/vote to formalize the Circle according to the current Governance Policy. If the proposal/vote passes, the Circle is formalised.

     

    Role assignments, quests and contributions can only be proposed for a formalized circle. At this stage in Samara all the assignments, contributions and quests need to serve the objectives of a circle and be proposed from within a circle.

     

    When there is a change in the work, focus, structure or areas that the outline describes, circle members can propose updates to the Circle Outline by creating a new proposal in the same Loomio thread for the specific circle. 

     

    Formalized Circles update their Outline Proposal every 6 lunar cycles, by presenting new objectives and KRs. If a formalized circle doesn’t propose and receives the passing vote for an updated Outline Proposal in 6 lunar cycles from the previous one, the circle is no longer a formal Samara circle and contributions to the circle can no longer be active.

     

    1. Recommendations for organizing within a circle

     

    Ideally, the circles keep the no. of members at 3. This has proven to work really well in Samara for people to be able to coordinate activities and schedule calls easily. 

     

    Whenever there are more than 4 people in a circle, members will look for ways to create a sub-circle of one specific circle. For example, if 3 people join a circle with 3 already in it, they can create two sub-circles of 3 and come together as a group after developing work that needs more minds. Circles have autonomy in how to organize and collaborate with sub-circles.

     

    1. How to join a Circle in Samara - Role assignments, quests and contributions

     

    Samara members can join a Circle by creating and submitting a role assignment, a quest or a contribution proposal. All these contribute to the objectives of the circle, according to that Circle’s Outline and purpose. 

     

    A role assignment is a commitment to a set of activities, with regular compensation for executing those activities. Roles can be time-bound, but are generally longer-term. Roles can be designed to accommodate various commitment levels. 

     

    A contribution is a specific key result that has already been completed paired with a request for remuneration. 

     

    A quest is a specific proposed objective or set of objectives, paired with measurable Key Results (OKRs) and a compensation request. Quests are generally time-bound, and can have one or multiple participants. If the participation in a quest is voted by Samara, quest member(s)

    execute it and return for a completion vote, at which point the compensation for the quest is received, if accepted. 

     

    Proposed role assignments, contributions or quests for every Samara Circle are voted in by the entire organisation, following the Governance process in place and using Loomio. 

     

    Proposed assignments, contributions or quests for a circle ideally need to be vouched by the existing members of the circle before being submitted as a proposal for vote on Loomio by the entire organisation. If a member refrains from vouching on a proposal he or she will provide additional information on why they do not vouch for the proposal.

     

     

    Members role - assignments for Circles:

     

    This is a 3 step process in order to enhance our ability to ‘murmur’ together:

     

    How the process works:

     

    Quests proposals:

     

    Contributions:

     

    At this stage of Samara (before moving to the DHO platform) the role assignments and quests start being active at the beginning of a lunar cycle (either new, half or full moon, to be able to be accounted for easily in the spreadsheet).

    Samara Policies

    April 20 to June 10 Remuneration Protocol for Samara contributors

    For the period after ending the first Hypha quest, from April 20 to June 10, the following remuneration protocol applies:

    Timeline: