Commons-Oriented Open Cooperative Governance Model V 1.0

Introduction This document describes how our organization, The Commons Media Collective is putting into practice a modified form of the original Open Enterprise Governance Model (OEGM). We have adapted the original OEGM in order to fit our needs, to address our specific requirements and allow for future modifications. Notably, we have chosen an alternative to replace the original term “meritocracy” (and similar terms), in order to acknowledge the controversial and unattractive connotations attached to the concept of meritocracy. We are opting for the term “equipotential” (and related words). “Equipotentiality” refers to the equal freedom, opportunity and capability of everyone to contribute to the commons, by matching the needs for commons development with the freely given contributions of passionate labor provided by commoners. Source: Michel Bauwens, The Triune Peer Governance of the Digital Commons Both of these terms are subject to scrutiny and debate. Our intention is simply to describe the central concept of this governance model as equity acquired by effort. This model rewards constructive participation, and the reward consists of greater influence in the development of the organization, nothing more and nothing less. To read the original Open Enterprise Governance Model and our initial list of alterations, please read the links below. Open Enterprise Governance Model - Original Version Proposed alterations to the original Open Enterprise Governance Model As the backbone to our cooperatives' governance and economic system, this document is very thorough. We aim to use it as an updatable reference source for the practice of the Governance Model per se. Relevant sections can be consulted by using the Table of Contents above. For a simplified overview, please visit the links below: Commons-Oriented Open Cooperative Governance Model Overview

Overview

A Commons-Oriented Open Enterprise is a equipotential, community-based organization. Every aspect of an COOE is governed by 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 competencies are shared, based on contribution and peer review.

Roles and responsibilities

We distinguish two main types of roles in the the Commons Medial Collective field of influence and within the commons we work with. There is a certain amount of permeability between, while still being clearly differentiated:

• External Roles

• Cooperative Roles

The former describes our interactions with individuals who support and add value to our commons. The latter the individuals who are committed to the stewardship and growth of our coop and engage with its processes on a regular basis.

External Roles

Supporters

Please note that the original OEGM governance model began describing participant roles with the term “user” describing the entry-level role. Neither the term nor the description were a good fit for GMC, so we have renamed and redefined the role in keeping with our vision and anticipating the specific level of engagement and acknowledgement we've described as follows.

We will refer to individuals who have neither been surveyed nor tested for hands-on participation within CMC as “Supporters”. A supporter helps ensure that the enterprise (GMC) succeeds in accomplishing its mission while remaining true to its values.

It is also important to note that Supporters differ from Casual Members in that they do not provide any pro-bono translation content.

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

• Spreading the word(e.g., posting links to our work on social media, word-of-mouth awareness raising, etc.)
• Providing feedback: informing the coop 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).

Casual Members

Description

Casual Members are individuals who contribute translation or editing services to Guerrilla Translation, our Pro-Bono web-magazine. They do not, however, participate in the day to day workflow of the coop or have any responsibilities towards it. Accordingly, CMC doesn't expect any sort of accountability from casual members and, although whatever pro-bono credits their published work accrues is are measured, but not divested.

An example of a Casual Member is someone who does translation work on their own and then shares it with Guerrilla Translation, so the CMC can edit it and publish it on the 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, if we haven’t any other members free to take it on. Casual Members are qualified professionals with whom we have friendly, ongoing relationships, and who currently do not have any interest in joining the collective.

If the translation (or editing) work in a proposed casual relationship isn’t up to scratch, we will not edit it or publish it.Material contributed by Casual Members can only happen when time and circumstances allow, and won’t take precedence over our committed relationships with established team members.

Casual Members can approach the collective at any time and, should they wish to, can also take on the role of Supporters

Responsibilities

None. Casual Members don’t have to do anything for the collective – in terms of building our support structure and using our workflow tools, for instance. They can get in touch whenever they feel like it and we’ll do the same. But this is important: they shouldn't expect to have any priority over members of the collective, to be compensated for any of your contributions or to receive any paid agency work.

Future Incorporation as Coop Members

Casual Members whom we have a healthy working relationship with can test out to become coop stakeholders at any time. CMC will already have determined whether the candidate can translate and/or edit in accordance with our standards, so no further testing will be necessary, although we will likely ask candidates to take our survey. If coop membership is approved, any previously published translation work will be added to the New Members credit queue for eventual compensation.

Cooperative Roles

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Latent Members

Contributors are users who have completed work in an enterprise. Any user can become a Contributor; there is no expectation of commitment to the enterprise, no specific skill requirements and no selection process.

Contributors are eligible to be nominated for Membership.

As Contributors gain experience and familiarity with the enterprise, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated for Membership, as described in the next section.

Full Members

Members are Contributors who have shown that they are committed to the continued development of the enterprise through ongoing engagement with the enterprise and its community.

Any Contributor can become a Member; there are no special requirements, other than to have shown a willingness and ability to participate in the enterprise as a team player. Typically, a potential Member will need to show that they have an understanding of the enterprise, its objectives and its strategy. Most importantly, they need to demonstrate that they are aligned with the enterprise’s core principles and values. They will also have provided valuable contributions to the enterprise over a period of time.

A Contributor can be nominated for Membership by any existing Member. Once they have been nominated, there will be a vote by the Core Team (see below). Once the vote has been held, the aggregated voting results are published on the public forum.

Nominees may decline their appointment as a Member. However, this is unusual, as the enterprise does not expect any specific time or resource commitment from its Members. The intention behind the role of Member is to allow people to contribute to the enterprise more easily, not to tie them in to the enterprise in any formal way.

By the time a Contributor is invited to become a Member, they will have been guided through the use of the enterprise’s various tools as a user and then as a Contributor.

In addition to their actions as Contributors, Members will also find themselves doing one or more of the following:

• nominating Contributors for Membership
• voting on Core Team Membership (see below)

Also Members’ votes are binding.

It is important to recognize that Membership is a privilege, not a right. That privilege 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 enterprise.

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 Members

The Core Team consists of those individuals identified as ‘enterprise representatives’. The Core Team has additional responsibilities over and above those of a Member. These responsibilities ensure the smooth running of the enterprise. 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

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.

3. Decision making process

Decisions about the future of the enterprise are made through discussion by the entire community, from the newest user 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.

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

3.2 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:

• ‘agree’: agrees that the action should move forward
• ‘disagree’: disagree but will not oppose the action’s going forward
• ‘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)
• ‘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 user to 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’.

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

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

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

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

4. Credits: Contribution Tracking

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.

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

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

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

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

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

5. Conclusion

The Open Enterprise governance model comes from the more democratic end of the spectrum of control. But it is not a democracy, it is a meritocracy. It is a model that passes control on to those who are most likely to wield it for the benefit of all, rather than a minority interest.

Work organization is (generally) emergent. People emerge to do the work by simply doing it. If they are helpful, other people begin to trust them. In a healthy enterprise, this trust eventually results in explicit authority and responsibilities. This is called leadership. In traditional management structures, authority is granted from the top down regardless of any existing trust or respect. This is what most people would call a manager. Managers may also be leaders, but this is unfortunately more rare than it should be.

Given the nature of open participation in Open Enterprises, they don’t have managers, but they do have leaders.

There is a big difference between a leadership culture and a management culture. In most corporations, management = status = power. The people who have the most people working for them have the loudest voices in the direction of the organization.

In a healthy Open Enterprise, the people who 1) have good ideas or 2) get things done, are the ones that have the status and power. These are the people who tend to have lots of folks start to willingly follow them.

First you earn leadership, and then you are allowed to manage.