Samara Policies
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.
https://eregs.github.io/guidelines/
How policies are decided
- The new policy is drafted in this book (create new page and assign a sponsor)
- The new policy is discussed and refined (allow editing and keep revisions)
- The Samara organization is voting on the policy
- Freeze editing and set status (admin only)
- Loomio vote (link to the policy page) OR
- DHO 90/30 vote (when available)
- When passed, the policy is enacted
- Change status to passed and add date
- Assemble team and timeline to execute policy
- When updated, the policy is amended
- Freeze is lifted (admin only)
- Note is added for amendment
- Make edits (try to do in one session)
- Policy is voted on again (#3)
- Link to revision page is added
Samara Policies
What policies are needed
(note: this is an initial stab at a list, by far not complete)
Finance & Payroll Policies
- Payroll & compensation (tokens & formulas)
- Funding & allocating (investors & tokens)
- Genesis contributions (value & voice)
- Treasury (redemption & accounting)
Governance Policies
- Badge multipliers (skills & achievements)
- Membership criteria (level & voice)
- Decision methods (quorum & unity)
- 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
- Activities/RNA (assignments, contributions, quests, #length-trial, #length-regular)
- Organization/DNA (##tokens, %token-decay, ##composite salary, ##complexity bands, &policies, &circles, &role-archetypes, &badge-archetypes, &org-archetypes, @accounting, @treasury)
- Voting Methods (%quorum, %unity, #length, ?blocking, ?5-scale, ?dynamic quorum, ?accelerated voting, ?high pass filter)
- Voice (%voice-decay, ?voice-delegation, ?account or token-based)
- Brand (#color schema, &logo, &identity)
- Communications (?on-chain or off-chain)
- https://wiki.hypha.earth/en/finance-policy (example Hypha 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:
- historical contributions (recorded in Google sheets)
- personal contributions (work done on the side) confused by difference between hist & pers. if it wasn't in the sheet, it wasn't compensated, right? not in monetary terms, or with comp = 0 Personal contribution is pre-proposed, but not explicitly part of a quest. Historical was arranged/added after the fact as I understand it.
- external contributions (financial or knowledge transfers) have we compensated knowledge? yes, me (to a degree)
- quest-based contributions (Hypha quests)
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.
- define HUSD need in advance (based on fiat needs)
- propose commitment (%)
- do the Co-Ev process at the end of commitment timeframe
- update commitment
- use 3 salary bands related with contribution (%):
- $70k for 1%- 49% contribution
- $90k for 50%-79% contribution
- $110k for >80% contribution
- compensate amount needed in HUSD and the rest in Samara tokens with 1.8 multiplier
Policy Purpose (Why)
- to simplify and improve the above interim model
- to anchor the compensation model on the approach outlined in The Chronicles of Samara and
- to better integrate 4 key components of compensation:
- Mindshare (how much of your life you give to Samara)
- Complexity (the anticipated intensity or difficulty of the work you do for Samara)
- Value (the actual value your contribution brings to the organization)
- Bonus (the go-above-and-beyond recognition as a generic multiplier added on top)
To simplify the above interim model, we need to reconsider:
- pay out HUSD per collective schedule, not per individual need +1. This is why paying a maximum amount, at least when there is less than 3-4months reserved HUSD makes sense.
- uncouple commitment from contribution and salary bands
To integrate the 4 key components, we need to revisit the compensation model and start at the bottom:
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)
- try to move the salary discussions off the table so that they are no longer front-and-center (this is a major source of contention in any organization)
- try to stay away from any competitive measures (that lead to comparisons, e.g. my experience vs yours, my commitment vs. yours, my needs vs yours etc)
- find a compensation model that is (1) fair and equitable for members, (2) allows for a personal growth pattern, and (3) aligns with the goals of the organization
Key principles (TBD)
- everyone has the freedom to choose their distribution of mindshare
- the overall distribution across all activities cannot exceed 100%
- you are encouraged to adjust your commitment levels accordingly
- there is no connection between level of commitment and complexity
- the circle (pod) decides what the level of complexity is for a given task/quest/role ("job")
- intense or difficult tasks/quests/roles are rewarded higher
- simple or repetitive tasks/quests/roles are rewarded lower
- alternatively, all tasks/quests/roles are rewarded equally
- the organization decides if the task/quest/role has contributed value to Samara or not
- tasks are proposed and voted on by each member
- quests are co-evaluated for each milestone and member
- roles (assignments) are evaluated and re-confirmed every 3 months
- the salary is based on a compound token model
- any work activity will earn 2x SVOICE in USD equivalent terms (investment activity is 1x)1
- What does the 1 reference to? Find it interesting that there is the suggestion of voice with investment. I would instinctively avoid this while recognizing that investors may well want some say in how the org works. In the end this is a choice about what Samara values most.
- long-term contributors are expected to earn proportionally more SAMARA tokens ("deferring", "having skin in the game")
- incentives for SAMARA tokens include a 1.8 multiplier that degrades over time
- any work activity will earn 2x SVOICE in USD equivalent terms (investment activity is 1x)1
Band Definitions
- $70k annual salary
- Relatively Low Complexity - focused on doing - minimal time sensing and on calls - maximum time DOING!
- 60/20/20 - Doing / Sensing / Learning (within one circle)
- $90k
- Requires much more headspace and managing overlapping topics, issues, information etc. Supporting multiple individuals.
- 40/40/20 - Doing / Cultivating (Sensing & Coordinating) with multiple individuals & circles / Learning
- $110k
- Supporting and serving multiple circles, individuals, and the movement effectively.
- 20/60/20 - Doing / Cultivating (Sensing & Coordinating) with multiple circles & organizations / Learning
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.
- 100% Samara tokens, adding the multiplier in place
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.
- Contributors can choose a HUSD component up to 30% of their total contribution (unless HUSD reserves are low, in which case a cap is placed on total HUSD per month any one person can request. This cap is based on the amount that will ensure reserves do not reach 0, which becomes more and more important as operating costs besides compensation come into play).
- Contributors can choose liquid Seeds component within a total of HUSD + liquid Seeds being up to 50% of their total contribution. (Low reserve proviso same as above).
- The balance to 100% is made by Samara tokens, adding the multiplier in place
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).
- define HUSD need in advance (based on fiat needs)
- propose commitment (%)
- do the Co-Ev process at end of commitment period
- update commitment
- use 3 salary bands related with contribution (%): 70k for 1%- 49% contribution, 90k for 50%-79% contribution, 110k for >80% contribution
- HUSD amount pay and the rest in Samara tokens with the multiplier in place
Examples (What)
- Jeff joins Samara as a new member and goes on an onboarding quest
- After completion, he earns an Apprentice badge, some SVOICE and is looking for a long-term engagement
- The XYZ circle has a new job posting at complexity level "B3" and archetype "building"
- Jeff applies and is accepted into the new role and starts his new assignment
- Each week month he claims to pre-defined tokens for the B3-Builder role
- 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.
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.
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).
Budgeting Process
The budgeting process breaks down into two parts:
- Overall allocation of funds routed to anchor circles (after deliberation and vote)
- 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
- Creating an initial pro-forma budget sheet with monthly estimates for all expenses [1]
- 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.
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.
[1] The Hypha Circle Budgeting Sheet
Governance Protocol
Samara decision making protocol
Proposal 0.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
- 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.
- 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.
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
-
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:
-
Name of the circle
-
Purpose
-
Aims
-
Accountabilities
-
Minimum commitment from members, if applicable
-
Objectives/KRs for 3 lunar cycles and for 6 lunar cycles
-
Distinguish between ‘Committed’ O/KRS and ‘Possible’ O/KRs to communicate areas of certainty and areas of possible impact
-
Total Circle Contribution % (sum of individual contributions)
-
Minimum / Expected / Maximum (Next Lunar Cycle)
-
Minimum / Expected / Maximum (Subsequent 2 Lunar Cycles - cycles 2-3 from start)
-
Minimum / Expected / Maximum (Subsequent 3 Lunar Cycles - cycles 4-6 from start)
-
Basic Badges
-
A circle proposal must include: Lamplighter + Scribe
-
Each Circle agrees on a standard facilitation process as a regular rhythm.
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.
-
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.
-
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:
-
Persona profile is done once per person, ideally during on-boarding quest (refined as needed) however the person likes with the suggestion to look at others and make it holistic.
-
Form + Role proposal which translates profile into purpose in circle is done when joining a circle
-
Objectives + KR’s, activities and commitment, compensation, vouching, start date and duration which speaks to specifics of role in action is done at start of new cycle/s (a few days before previous committed cycle end date after first time).
How the process works:
-
All members produce a persona profile in order to join a circle, to honor, presence and share their uniqueness and speak to how that meets Samara. Specifically includes:
-
Holistic personal expression of how we see our natural strengths and roles and what others appreciate about us in work-play.
-
Naming capacity we have learned to be ‘good at’ and tend to start doing easily, but if overused causes stress and ‘degeneration’.
-
Work, hobby and life experience that speaks to the essence of contribution in Samara.
-
Personal Purpose + Purpose in context of Samara.
-
All members fill out a standard inquiry form to detail the role proposal for the circle. This links natural role with circle purpose.
-
Purpose of this is:
-
To be included in people board to help synchronous connections as Samara scale’s and give a welcoming sense to new people
-
Establish a shared cultural language that allows expression embodied in persona profile to speak to the same areas/questions
-
Encourage full-spectrum expression of potential (all levels, all lines)
-
Circle where the role - assignments contributes to (one person may have many role-assignments speaking to each circle they are committed to around a single persona profile)
-
The Circle Objectives and KRs which the member intends to contribute towards
-
Individual/Personal activities that contribute to the circle KRs
-
Commitment (%) to this circle
-
Compensation: to be proposed according to the Remuneration Protocol in place
-
Vouched by:
-
Didn’t get vouch by: (with additional information)
-
Start date of the assignment (next half, new or full moon)
-
Duration (no. of cycles - max 3)
Quests proposals:
-
Circle where the quests contributes to
-
Purpose, objectives and KRs
-
Members proposing the quest, if several
-
Compensation required - to be proposed according to the Remuneration Protocol in place
-
Vouched by:
-
Didn’t get vouch by: (with additional information)
-
Start date of the assignment (next half, new or full moon)
-
Duration (no. of cycles)
Contributions:
-
Circle where the contribution took place
-
Purpose, objectives and KRs accomplished
-
Members, if several
-
Compensation required
-
Vouched by:
-
Didn’t get vouch by: (with additional information)
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).
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:
-
All Samara members who contributed in this period propose the contribution (%) they feel they had during this time, by filling the spreadsheet “Compensations”;
Note: Recommend to read the section on mindshare in Samara Chronicles to help you define the contribution https://guide.hypha.earth/books/the-chronicles-of-samara/page/samaras-compensation-model -
We do the Co-Ev
-
Samara members can update their contribution (%) following the Co-ev process (recommendation not obligation)
-
The salary bands related with contribution will be determined in the following way: 70k for 1%- 49% contribution, 90k for 50%-79% contribution, 110k for >80% contribution
-
All contributions will be remunerated with Samara tokens at a multiplier of 1.8.
-
3 Samara members were remunerated with HUSD in this period (following the proposals being voted on Loomio).These members will receive the balance of Samara tokens to match their total contribution.
Timeline:
-
Propose contributions (%) by June 10 (the sooner the better)
-
Co-ev process: June 11 - June 14
-
Update contributions (%) - June 15
-
Finalise and update Stokens and SVoice on June 16
Note: This protocol applies to everyone who has been with Samara in this period and has the intention to further contribute and not only to those who were part of the first quest.