Commons-Oriented Open Cooperative Governance Model V 1.0

Overview

This document describes a governance/economic model for mission-oriented distributed organizations offering services in the marketplace.

It values pro-bono, care and market work with complementary metrics and doles out payment accordingly. The purpose is to extract people from the capitalist marketplace so they can use their unique talents to do fulfilling, social and environmentally meaningful work. The document prototypes a governance model fit for digital labor and applies it concretely to an existing organization: the P2P translation collective Guerrilla Translation which is, in turn, embedded into a larger proto-organization called the Commons Media Collective.

It is a substantially developed fork of the Better Means Open Enterprise Governance Model (OEGM). The adaptations have been made to:

1. bypass the original model’s start-up/for profit oriented lingo
2. fit the needs and ideals of Open Cooperativism and Open Value Networks,
3. benefit, commons-oriented market entities self sustain their social vision. while addressing their specific requirements and allow for future modifications.

An OVN Coop is a equipotential, commons-oriented and community-based organization. Not all Open Coops are OVN’s and not OVN’s are Open Coops. What we offer here an opt-in engagement model: this means that anyone who is participating in CMC as a member or contributer will have their work valued, and will be expected to participate in the decision making process. Decisions and control are shared, based on contribution and peer review.

This model outlines the responsibilities of different roles within the organization by allowing its stewardship to be held by those who have demonstrated willingness and invested personal effort participating in its goals. By endowing those who have offered the greatest demonstrated investment with the most decision-making responsibilityhttp://wiki.guerrillamediacollective.org/index.php?title=Commons-Oriented_Open_Cooperative_Governance_Model&action=edit and influence, the strategic development of the organization is entrusted to those with the greatest stake in the outcome of those decisions. Nothing is ever foolproof, but this modified model serves as our intention to protect and provide for those who have participated in building our strong foundation.

To see how we envision this in practice, we’ll be using Guerrilla Translation as a showcase example, but it’s important to stress that the model is designed to be useful to other organizations, whether they’re part of the Commons Media Collective, or independent from it altogether.

Want to comment? For general comments, use the discussion page. For in-text comments, corrections, etc, use this colaborative document.

The Open Cooperative Model in Guerrilla Translation

TL,DR: In Guerrilla Translation, members undertake both pro-bono and agency translation/editing work. Both types of work are accounted for in internal credits (1 credit = 1 Euro). Once a month, GT’s account is distributed: 75% of holdings goes to fulfil each members agency/livelihood credits queue, 25% goes to fulfil the pro bono/love queue.

The following example is a simplified explanation of how the model works. We’ll get into the nitty-gritty and open questions in later sections.

Guerrilla Translation (GT) begun its life as an activist translation collective. Guerrilla Translators are politicised, conscious translators. Their motivation? To create a plurilingual knowledge Commons, accessed through GT’s websites (English and Spanish so far). But it is also a translation/language agency offering a series of services. The governance model is what ties these two facets together.

What this looks like in practice

So “Jill the Guerrilla Translator” chooses an article to be translated. Maybe she’s proposed it, or maybe she’s picked it up from a common-pool of to-be-translated material. She then contacts the author to let her know GT is going to translate and publish it, ask permission if necessary etc.

The thing to keep in mind is that this will be a pro-bono translation. Jill will work on it with “María” a copyeditor and “Deb”, who’ll take care of the web formatting and social media promotion of the article.

The article is 1000 words long. This wordcount is then processed through GT’s internal credits system. This means that this Pro-bono translation is valued a 0,16 credits per word. Once the translation is finished, 160 Love credits (LCs, for this is what they're called) have been created. This is how they are split:

• 80 to the translator (Jill)
• 40 to the editor (María)
• 10 pre production (Jill, as she contacted the author)
• 20 formatting (Deb)
• 10 post production (Deb, as she’s doing social media, etc)

So, let’s imagine that this is the first time that Jill, Maria and Deb have done a pro-bono projectfor GT. Once the project is accounted for, their respective pro-bono piggy banks look like this.

• Jill has accrued 90 Love Credits
• María has accrued 40 LCs
• Deb has accrued 30 LCs

A week has passed an an author or client wants to contract GT to translate an article. This is seen as livelihood work. The material is chosen by the client, the deadline negotiated with the collective. Coincidentally, the text to be translated is also 1000 words long. Amazing! GT’s agency side uses a sliding scale for prices. This client is a sufficiently funded small NGO, so the price quoted in 0,12 € per word and the the team will be Jill (as a translator) and María as editor (bear in mind that, for this example, there is no web formatting to be done). Once the translation is completed the client owes GT 120 €. Now, these will not be paid directly to Jill and María, but are accrued as Livelihood Credits (LHs) going into separate piggy banks:

• Jill has accrued 80 Livelihood Credits
• María has accrued 40 Livelihood Credits

For the sake of simplicity, we’ll assume that this is the only pro bono and agency work done in the collective’s history. It's getting toward the end of the month and the Guerilla Translators are ready to distribute! There are exactly 120 euros in the bank account. This is how they will be distributed:

• 74% of the funds will fulfil Livelihood credits.
• 25% will fulfil pro-bono credits
• 1% is held in the bank (ice cream fund or, basically,money left in the back to keep the account alive).

These percentages have been chosen to offset time for paid gigs with the vital pro-bono side (AKA: "The Heart of Guerrilla Translation". No pro-bono, no love!). So, given that we have 160 € to dole out, we'll split them like so:

• The Livelihood Stream receives 88,80 €
• The Love Stream receives 30 €
• The Ice cream fund keeps 1,20 €. Take that, bankers!

This is now divided among the member's piggy banks in the following way:

In the Livelihood Stream Jill holds 67% of the "shares" (80 credits of a 120 total), while María has 33% (40 credits of a 120 total). So out of 88,80 € allocated for the Livelihood Stream Jill will receive 59,50 €. María receives 29,30 €.

In the Love Stream Jill holds 56% of the shares (90 credits of 160 total). María has 25% (40 out of 160) and Deb has 19% (30 out of 160). So, out of 30 € allocated for Love Jill will receive 16,80 €, María 7,50 € € and Deb 5,70 €.

All added up, this is the money that gets paid to the three active members:

• Jill gets 76,30 €
• María gets 36,80 €
• Deb gets 5,70 €

This totals 118.80 €, remember that 1.20 remaining is the Ice Cream fund. More on that later.

An example among many

This is one situation. Another month María may have done a lot more editing work (which takes less time). Deb may have done more carework (more on that later) in both the Love and Livelihood streams. New people may have come in, maybe there's been a windfall! The model can account for all those possibilities, and more, while also being dynamic and adaptable to changing circumstances. It's a "Team Human" mode, where the technology is kept flexible and updated to serve the qualitative experiences of the collective, not just the measurable ones.

The secret life of Livelihood, Love and other credits

As you may have noticed, if 1 love credit equals 1 euro, in the example above we've only paid down 30 credits (25%) in Euros. As 160 Love credits were created with the pro-bono translation this still leaves 130 which haven't been paid in money. This last part (money transferred to individual's accounts) is what we call divested credits, ie: they've been paid down. The unpaid Love credits are considered Invested credits: active credits that have yet to be paid. If you think about it on a month by month basis 75% of Love credits will be "invested" rather than paid. In essence, the coop has a debt with its own pro-bono stream which will be paid back in a rolling basis.

Also, maybe the client that owes the 120 € at the end of the month hasn't paid and we can't divest those credits into Euros? In that case they'd be "invested" until there are funds in the account.

These are some of the types of credits handled in Guerrilla Translation. "Why so many? So confusing!" We get it, but complexity allows for dynamism and nuance. We'll get into the various types of credit and their functions in a section below. For now, it's important to make clear that the total amount of credits you have accumulated (both divested, invested... the lot) accrue to give you G-chi. G-chi reflects your investment in the organization, through paying work and sweat equity and directly informs its governance. The more G-chi you have, the more it is understood that you have poured your soul into the collective and will be affected by its health. More G-chi means more influence and decision making power within the collective's governance.

Why have we chosen this model?

Imagine that María is single mother with two kids to take care of. She wants to do socially useful work, but her material realities don't allow her that privilege. By working with Guerrilla Translation she a) Gets agency work for causes that matter and b) is not "losing" income by doing pro-bono work - ie, translations that wouldn't get funded otherwise, but should still be translated. In fact, she could spend all of her time just doing agency/livelihood work, and it would still benefit the pro-bono/love side and vice versa. The model addresses the possibility of internal competition for "paid work" overshadowing the social/activist mission of the collective. In short, contributing to the Commons also makes your livehood more resilient and, in turn, you make the Commons more resilient by creating new commons and facilitating communications.

The Commons-Oriented Open Cooperative Governance Model in detail

After this overview of how the model works, we will now break down its components in more details, as applied to Guerilla Translation. We will be covering:

• Roles and responsibilities
• Decision making processes
• Credits contribution and tracking

Roles and responsibilities (in ascending order of participation)

There are various levels of engagements within the collective. It has, in fact, designed to be porous with the main distinction being "casual" and "committed" relationships, (think of dating). In short, casual relationships function more like a commons-based peer production project, such as Wikipedia, Firefox or the VLC video player. Contributions are permissionless and validated after the fact. Everybody is welcome to contribute but translations will only be published if there's an editor available. Additionally, there is no agency work or pro-bono payments doled out to casual members (although pro bono work is accounted, maybe they'll become committed further down the line).

Committed relationship work more like a traditional Commons: clearly established boundaries, governance protocols and accountability. This also makes more akin to a Coop: the members watch out for each other and are dependent on their shared trust. Committed members are worker-owners of the agency side of GT (think of it as their day job) while assuming the responsibility of upkeeping the pro-bono/commons-producing side.

Supporters

We will refer to individuals who want to engange with the collective but are not interested in translation or care work as “Supporters”. A supporter helps ensure that the collective (CMC) succeeds in accomplishing its mission while remaining true to its values.

Supporter contributions could include (but are not limited to):

• Evangelizing about the collective (e.g.,  posting links to our work on social media,word-of-mouth awareness raising, etc.)
• Providing feedback: informing the organization of strengths and weaknesses from a new supporter's perspective, which will help to  keep us accountable to our mission and values.
• Providing moral support, including simple acknowledgement (a ‘thank you’ goes a long way).
• Participating in  open discussions: commenting on Work Items, and in the forums
• Supporting the collective monetarily: This includes donations, Patreon supporters, funders etc.

Supporters can engage with Guerrilla Translation through email or social media but, preferably, through an open Loomio group for that purpose. In time strategies can be studied to use the Loomio group for polls etc, *

Casual Relationships: Contributors

One example of a casual relationship is someone who does translation work on their own and then shares it with Guerrilla Translation, so GT can edit it and publish it on their web magazine. Another example is when GT contacts a close associate outside the collective to see if they’d be willing to edit a translation at their own pace when GT hasn’t any other members free to take it on. The key here is that the people in question are qualified professionals in GT's chosen field (translation, editing) with friendly, ongoing relationships, and who currently do not have any interest in joining the collective.

From time to time people will write to GT wanting to hook up – sending a translation they’ve done, or similar – but there's no "history" between these people and the collective. GT might find that the work is excellent, but maybe not. If the translation (or editing) work in a proposed casual relationship isn’t up to scratch, GT will probably won’t be dating with this person. Conversely, if both parts reach a clear, mutually respectful understanding, they will probably keep collaborating in some form or other. Again, extending the metaphor, these casual relationships can only happen when time and circumstances allow, and won’t take precedence over committed relationships with established team members.

What are the contributor's responsibilities? And the collective's to the contributors?

None! To be clear: if a contributor sends a translation and it causes the editor a headache, then "we’re really not made for each other". Casual relations are consent-based and depend on clear communication.

A casual contributor doesn't really have to do anything for the collective – in terms of building our support structure and using GT's workflow tools, for instance. Contributors can get in touch for a booty call whenever they feel like it and vice-versa.

But here is the important bit: Contributors shouldn’t imagine they’ll have any priority over members of the collective, or that they’ll be compensated for any of their contributions (poor unicorns!). A casual relationship is based on a respectful coincidence of wants and needs.

What contributors get out of a casual relationship with GT

If the submitted translation or editing work is of sufficient quality and the mutual experience is a happy one:

• GT will publish and promote the work in its web magazine.
• Contributors don’t have to worry about learning GT's practices as a Commons or undertaking any of GT member's basic responsibilities.
• Whenever a Contributor wants to test out as a member and join the collective “for real”, both parts will be ready to take the next steps. GT will already have determined whether you the Contributor translate and/or edit in accordance with the set standards, so no further testing will be necessary, although a call should be set up to explain what becoming a member in a committed (but not exclusive!) relation with GT is all about. Any published translation work will be valued for eventual compensation, once the contributor has joined.
• If after having an honest chat about what it means to be in a omitted relationship, both parts don’t want to get involved for whatever reason, sorry, they’ll have to part ways. As stated above, casual relationships (like any others) must be based on consent, and obviously you can’t force anyone into a relationship. Contributor obviously have the same right to tell GT that they’re not interested, too. ("It's not you, it's ME!" etc)

What about non translation casual relationships??

People can approach GT from time to time wanting to help with non-translation tasks etc. These can be treated on a case by case basis, but this poses more difficulty than easily measurable translation/editing work. It will be up to those dealing with carework to devote time to this but, in general, we recommend that carework be dealt from within the organization, as committed members, etc.

Committed relationships: Members

A "Member" is the next step up within the organization. Membership level engagement also marks the (porous) frontier between casual and committed relationships with the collective or, if you prefer, between permissionless Commons-based peer production type interactions or those of a concrete commons or cooperative. Again, for more details on casual vs. committed relationships read Guerrilla Translation's article To be or not be a Guerrilla Translator, which is routinely shared with anyone approaching the collective to ensure clear understanding of what GT is and isn't.

In short: Members can either be proven contributors who have shown that they are committed to the continued development of the collective or newcomers who would like to apply directly for membership without going through the "casual" phase. The important thing here is that Members:

• a) Go through GT's Applicant Evaluation Criteria and Procedures
• b) Undergo an initial test to determine translation/editing/carework ability
• c) Have an interview with a Core team member.
• d) Go through a quarterly evaluation phase and meet basic responsibilities.

As far as GT is concerned, all these steps are detailed in the links above, but we'll briefly summarize them to illustrate them model:

Applicant Evaluation Criteria and Procedures

Before getting "committed" and spending time and love on new members, GT has to make sure that the relationship will be a good fit. Of course this is hugely subjective and there's no perfect model but, like relationships, clarity of communications an intentions is key. GT is speficically looking for:

• Ability to translate (and/or edit) into at least one target language
• Interest in working in a co-operative collective group
• Good skills for working independently and remotely, including time management and communication
• Strong interest in enough of the topics we cover
• Willingness to learn our procedures, tools, governance model

This is determined through a series of procedures, including a short essay by the prospective member on why she/he wants to be committed, a translation and/editing test and a video chat. Above all we value reciprocity and carework. GT's model is NOT simple and, like most self-organized collectives, involves a learning process.Think of it as moving in with someone or sharing a flat (our “relationship” metaphor doesn’t necessarily have to mean “romantic” for our examples to work). You can save money, have more support, build stronger futures, but it’s all dependent on what you put into it. GT's commitment is to facilitate this process with excellent attention and availability. If the prospective member wants to commit, she/he has to be crystal clear on what is expected before taking this step. If it's a mutual "yes", the next three months are key for leaning how to work with the collective:

Testing phase and basic responsibilities

When both parts are happy about going forward and investing our time in the relationship (ie, “going steady”) they’ll still be, in the words of Sly Stone, “Checking each other out”. Those first few steps within the collective are summarized and detailed in GT's wiki’s “Welcome” entry.

First impressions can be great, yes, but it’s the months following that will make or break the relationship. Again, it’s all about clear communication and consent. When we talk about three months to see how everyone works together this is not just limited to new members, in fact every member of the collective is subject to the same basic responsibilities and criteria. These can be explored in more detail in this link: Ongoing Evaluation Criteria and Basic Responsibilities

In GT these responsibilities basically amount to keeping in touch with the team and translating some material for the web magazine. It amounts to approximately two full days of work out of those three months. It makes the most sense to spread it out, so we think it’s pretty easy. Anyone serious about joining GT or any collective using a similar model ought to meet or - preferably, exceed - those responsibilities. In more detail, they include:

• Reading a becoming familiar with the working procedures of the collective. (For GT translators this is all detailed in a thorough tutorial called The Tao of the Guerrilla Translator.
• Accruing a minimum of 400 Love credits by doing a number of pro-bono translations, editing or formatting tasks. Carework also adds to these credits.
• Be familiar with the collective's tools and procedures. In GT that means Loomio, Trello and The Wiki and how they interact.
• Keep up with all deadlines and commitments in a professional and responsible manner.
• Answering any communications and keeping the collective up to date about availability.

The testing will normally take place over three months, but these must be in synch with a quarterly calendar. This is done so the collective can batch all team evaluations at the same time. If a candidate joins in the middle of these, that's fine too, but the final evaluation will take place at the end of the next quarter, along with the rest of the team. During the first quarter candidates are not obliged to obtain a proportional amount of love credits, but it's a good metric for initial feedback.

Once three months have passed there will be a mutual evaluation. Is the new person happy with the relationship? How about the collective? Has the person met the minimal requirements? If it's all yes, great, full speed ahead. If not, better to cut the relationship now. No bad vibes.

Members beyond the Testing Phase

Once a member has passed the testing phase, she/he gets a few perks, including:

• Choosing material to be translated according to GT's Content Curation Guidelines.
• Having biding decisions in online votes and decisions (see below)
• Doing livelihood/agency work
• Enter the monthly payment pipeline (Including a payout of accumulated credits during the Test Phase)

Full members are, however, subject to the same responsibilities outlined through the Test Phase. Q

What happens when a full member doesn't meet the quarterly quota? And if they leave?

Full, committed members get extra love and understanding from the collective. The key here is, once again, clear communication. If you're going into a three month retreat, go you! They only thing you'd have to do is tell the collective that you're taking a sabbatical quarter, six-months, year, whatever.

Let's imagine it's a sabbatical quarter: In this case the member keeps all their invested credits frozen until the next quarter, when they will be weighed as shares for monthly payouts, minus 400 credits which frees them up from meeting any pro-bono obligations during the sabbatical period. Members are free, of course, to do translations on their own during this time, which will be credited once back in the flow of things. They can also do 800 credits for the next quarter if they don't want to lose any.

Even when something unexpected happens and no sabbatical has been planned, that's OK, but those 400 divested credits will be deducted automatically. Exceptions to this logically include being sick, family situations etc. In those case the credits will be frozen or, if needed for emergencies, divested.

If a member vanishes without a trace and doesn't check in every quarter to inform of what's going on then, unless they've been the victim of a 3-month EMP blackout, there will be a split with the collective. Please write a break up letter, as the collective will become better because of it. Credit piggy banks will be cancelled, increasing the shares of other members.

When and if a member decides to leave all together, they will "cash out" all divested credits. Whether it's a flat payment or staggered across several months will depend on the collective's finances and will be decided in a vote. Splits are considered final, it is much preferable to take sabbaticals and keep a good relationship, specially when both parts need to give each other some space!

What members get out of a committed relationship

GT members create shared value together, and the result of this value reverts back to the individual members. Members of the collective, assist with its development, co-creating and facilitating commons, and are rewarded for their work. All pro-bono translation or editing work published has a value attached to it, the same as livelihood or care work. This value will be fulfilled on a regular basis as the collective continues to build an income stream.

As explained above, members share work and income proportionate to their investment and commitment to the collective. The more they sow, the more they reap. The minimum requirements are the bare minimum, and while it’s ok to stay at that level, any members that decide to put more time and effort into the collective will be adequately rewarded for it.

It is important to recognize that Membership is a commitment, not a right. Membership must be earned and once earned it can be removed by the Core Team (see next section) in extreme circumstances. However, under normal circumstances Membership exists for as long as the Member wishes to continue engaging with the collective while meeting its requirements.

A Member who shows an above-average level of contribution to the enterprise, particularly with respect to its strategic direction and long-term health, may be nominated to become a Member of the Core Team. This role is described in the next section.

Core Team

The Core Team consists of those individuals identified as the main representatives of the collective. The Core Team has additional responsibilities over and above those of a Member. These responsibilities ensure the smooth running of the collective. Core Team Members are expected to participate in strategic planning, approve changes to the governance model, and formally represent the enterprise to the outside world. First and foremost, they are the guardians and keepers of the enterprise’s principles and values, and are accountable to all stakeholders.

Core Team Members do not have significant authority over other Members of the community, although it is the Core Team that votes new Members in. In addition to their actions as Members, Core Team Members will also find themselves doing one or more of the following:

• voting on nominated Members
• voting on changes to the governance model
• nominating Members to the Core Team
• Core Team Members may declare a ‘vote-by-credit’ vote (see below).

Core team members are stewards of several areas. This means that, although they may not directly work in any of these aread or be the main contributors, they are mainly responsible for their upkeep. In GT these areas are:

• Vision and values steward
• Economic and Governance Model steward
• Carework steward
• Linguistic work steward

Membership of the Core Team is by invitation from the existing Core Team Members. A nomination will result in discussion and then a vote by existing Members of the enterprise. Core Team Membership votes are subject to consensus approval (see below) of enterprise Members.

Core team members are also eligible to accrue credits on a time-basis (as opposed to a credits basis). This is explained in more detail below.

The issue of care work

So far we have spoken about tangibles. Translations, editing, blog posting etc. As these tasks are mostly word-based they are easy to quantify and assign credit for. But what about everything else? All the invisible work that goes into holding the relationship together.

One of the biggest unsolved issues in GT so far has been how to take responsibility of and reward carework appropriately. There is a whole wiki article written to explain what carework consists of, which you can read here. But to summarize, in GT carework can include contacting authors for translations, promoting posts in social media, seeking paid gigs and following up on them, accounting, member evaluations, forging alliances, attending meetings, training new members, keeping GT's online and learning materials up to date... this is no small thing!

In GT it was initially decided that ALL translators/editors devote some of their time to carework so they'd be no fixed roles and every full member took an equal stake in the responsibility of caring for the collective. Another option was to try a weekly rotation. Neither worked at all, many translators bypassed or made perfunctory attempts at carework, passing it on to other people who, as a result, had no time to translate, accrue love credits or engage in agency/livelihood work. The fact is that carework needs special abilities (just as translation) which necessitate a an important investment of time.

As of writing, there is no agreed upon solution, but here are some ideas to discuss and develop:

The majority of Carework can be handled by the Carework steward. This is trusted Core Team member tasked with ensuring that all care work tasks are met and of assisting other members to help with carework. This includes training and assistance for both Committed members and casual relationships. Carework will still be a team effort and members ARE expected to participate, but there will always be a lead person.

How to value (and compensate) care work

It would be impossible to itemize/quantify all the tasks involved in carework.We need to decided which tasks (low hanging fruit) CAN be itemized. Think social media work, accounting... any task that is repetitive and can be easily accounted for in advance can still remain a credit based task. Furthermore, these "accountable" tasks can take place in both the Love and Livelihood Streams, giving everyone the chance to take on various tasks and see the whole machine works. It's important that members don't limit themselves to the "translation" bubble, or whatever service the Open Coop offers to meet its livelihood responsibilities. Think "Art and the Art of Motorcycle Maintenance". We need to think in how to encorage and make this as easy and fun as possible.

For all non-measurable tasks (think contacting clients, training a new member, forging relationships, attending calls) the Care steward can be paid a full time salary. If she ALSO does itemized/credit-bound work, that is also added, but the idea is that she coordinates, helps other in the collective take on these tasks while "holding the center".

Payment XXXXX

This assumes a functioning governance/model, with working software and a well-greased collective. At present that is yet to come so, for what we've termed the "Start-up phase" we want to seek philatrophic funding to develop and implement the model, while rebooting the project. For this the Carework steward would be paid full time until completion of the start-up phase. Additional collaborators to the Start-up phase can also be paid, bearing in mind that the start-up phase can be seen as a time-bound project with concrete deliverables.

Decision making process

Decisions about the future of the enterprise are made through discussion by the entire community, from the newest supporter to the most experienced Core Team Member. All non-sensitive project management discussion takes place in public Workstream dashboards and forums. Occasionally, sensitive discussion occurs in a private Workstream.

In order to ensure that the enterprise is not bogged down by endless discussion and continual voting, the enterprise operates a policy of lazy majority. This allows the majority of decisions to be made without resorting to a formal vote, and keeps the work agile and red-tape free.

The Process

Decision making typically involves the following steps: 1. Proposal 2. Discussion 3. Vote 4. Decision

Anyone can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should add the idea to the appropriate Workstream dashboard or forum (work-item ideas go in the dashboard, big-picture strategy is discussed in the forums). This will prompt a review and discussion of the idea. The goal of this review and discussion is to gain approval for the contribution.

The Dashboard and the mechanism of Motions allow for work-items and ideas to be voted upon by the community. However different level of voting and approval are 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 lazy majority – that is, 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 very important concept within the project. It is this process that allows a large group of people to efficiently reach consensus, as someone with nothing to add to a proposal need not spend time stating their position, and others need not spend time reviewing it. This section describes how a vote is conducted. Section 3.4 discusses when a vote is needed.

For 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.

If a formal vote on a proposal is called, all users may express an opinion and vote.

There are 4 types of votes:

1. ‘agree’: agrees that the action should move forward
2. ‘disagree’: disagree but will not oppose the action’s going forward
3. ‘block’: opposes the action’s going forward and must propose an alternative action to address the issue (or a justification for not addressing the issue)
4. ‘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 to abstain, since this allows the team to gauge the general feeling of the community if the proposal should be controversial.

The entire community, from interested supporterto the most active Core Team Member, has a vote. The enterprise encourages everyone to express their opinions in all discussion and all votes. However, only Members of the enterprise (as defined above) and/or Core Team Members have binding votes for the purposes of decision making. It is therefore their responsibility to ensure that the opinions of the entire community are considered. While only Members and Core Team Members have a binding vote, a well-justified ‘block’ from a non-Member must be considered by the community, and if appropriate, supported by a binding ‘block’.

A ‘block’, when cast by a Member or Core Team Member, essentially becomes a ‘veto’.

When a vote receives a ‘block’, it is the responsibility of the community as a whole to address the objection. Such discussion will continue until the objection is either rescinded, overruled (in the case of a non-binding block) or the proposal itself is altered in order to achieve consensus (possibly by withdrawing it altogether). In the rare circumstance that consensus cannot be achieved, the Core Team will decide the forward course of action.

In summary:

• Those who don’t agree with the proposal and feel it would be detrimental to the enterprise if pursued should vote ‘block’. However, they will be expected to submit and defend a counter-proposal.
• Those who don’t agree, don’t find it detrimental, and don’t have a better idea should vote ‘disagree’.
• Those who agree should vote ‘agree’.
• Those who do not care either way or who find themselves on the fence should vote ‘neutral’.

Type of approval

Different actions require different types of approval, ranging from lazy majority to a majority decision by the Core Team. These are summarized below. The next section describes which type of approval should be used in common situations.

1. 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.

1. 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)

1. Credit majority

Some strategic actions are decided by giving each credit-holder 1 vote per credit; Such actions typically affect the foundation of the project (e.g. adopting a new governance model)

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 are taken through lazy majority, which is still informal enough for team to stay agile.

However, some activities require a more formal approval process in order to ensure the health and cohesiveness of the enterprise.

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

• Work Item moving to open queue and Work Item acceptance is dependent on the estimated value of that item:

o   0-1 points: Lazy majority of all Members, vote threshold: 1

o   2-4 points: Lazy majority of all Members, vote threshold: 2

o   5-6 points: Lazy majority of all Members, vote threshold: 3

• New Workstream: Lazy majority of all Members
• New Member: Unanimous consensus of Core Team
• Member removal: Unanimous consensus of Core Team
• New Core Team Member: Unanimous consensus of Members
• Core Team Member removal: Unanimous consensus of Members
• Governance model change: Credit majority
• Legal structure changes: Credit majority

Anomaly: Estimation is done by lazy averaging: Any Member can estimate a Work Item that is new or open. Estimation is closed once the item is in progress.

Credits: Contribution Tracking

XXX ADD INFO FROM HERE: [1]

Credits offer an exciting new way of tracking contribution that can be utilized as a compensation system or merely a contribution tracking system. The Credits module is an OPTIONAL module of the BetterMeans platform, however we believe it is a central and important module to the Open Enterprise Governance Model. Throughout this section, we will describe this system with the assumption that it is being used as the form of compensation for work, however know that in application is can be used however the team chooses to.

Credits

Credits are the measurement by which contribution is tracked. A Credit typically means $1 in compensation. Therefore if an item is estimated at 100 credits, and a person completes the work and is attributed 100% of the contribution, than that person earns 100 credits and thus is owed $100 for work completed.

Estimation

Each Work Item in an Open Enterprise is estimated independently, in terms of how many credits will be awarded for its completion. Any member is free to give an estimate of how much should be given for any open Work Item, and their estimation will affect the average estimate of that item. And once work starts on a Work Item and it is being executed, its estimation can no longer be changed. Only the estimates of Members and Core Team Members are counted as binding and affect the final average. Contributors and Users’ estimates are shown and are non-binding and should be considered by Members if they believe that the non-binding vote is based on better knowledge or expertise of the value of that work item.

Retrospectives

In order to ensure that all Contributors to a Workstream get adequately compensated for their work, and that compensation be as fair as possible, the compensation system in an Open Enterprise is based on several tenants:

• There are no fixed salaries in an Open Enterprise
• Participants are compensated based on Work Items completed, not time spent – This is to provide everyone the freedom to contribute as much or as little as they choose, and for the Enterprise to be billed fairly.
• Contribution is assessed by one’s peers, seeing as coworkers and co-team members are the most likely to know how valuable someone’s contributions were – This is to provide the most fair assessment of one’s contribution, using the wisdom of the crowd in assessing work done.
• Peer assessment is compared with self-assessment – This is to provide an opportunity for each participant to self-reflect and learn about their assessment of their own work, as well as an indicator to all users of each participant’s self-assessment abilities.

This system of compensation is executed using the Retrospective, which occurs once a number of Work Items worth a certain amount of credits are completed and accepted in any given Workstream.

During the Retrospective, each person who has contributed any amount of work to any of the Work Items involved is asked to assess their own percentage contribution to the completion of these items, as well as every other participant’s. Once all participants have stated their opinion, each one receives the average of their team’s assessment of their work. That figure is also compared with their own assessment of themselves, which affects their self-assessment reputation.

The percentage each participant receives is then applied to the total amount of credits associated with the retrospective and these credits are distributed accordingly.

Credits Queue

Once Credits have been awarded, they are tracked in the Credits Queue. This Queue demonstrates all the credits ever awarded, and in addition it demonstrates which Credits are active. When an individual decides to retire their credits, meaning that they have been paid or they are trading in their credits, they are able to do this from the Credits Queue. The Credits Queue is a way for people to see who has completed what and how and when people have been compensated for their contribution.

Volunteer Credits

In addition, any workstream can be declared as a volunteer workstream. In this system, item are still tracked and estimated with retrospectives to distribute credits. However all credits earned are volunteer credits and are merely a recognition of the hard work that a person has donated to a cause they believe in. Volunteer Credits give the owner the recognition and decision-making ability of a credit, but have no monetary value. In addition, the volunteer workstreams are an important signal to participants that their work will be volunteer in this context.

.