Proposed Charter of the Open Organizations Project

(0) PROBLEM

The structures that organizations typically use for decision-making are closed: individuals are unaccountable, abuses of power are hard to prevent and knowledge is hoarded. The goal of this project is to explain how to set up and maintain transparent, accountable and truly participative communities. The desire for open organizations stems from a widespread dissatisfaction not only with the formal power structures found in governments and corporations, but also with the informal structures found in many voluntary and activist groups. Informal structures are sometimes created intentionally, but more often they appear 'by default'; since they are hidden, and often personal, they are very difficult to challenge, or even to identify and discuss. This is one of the major causes of conflict in activist and volunteer groups. It often takes up a lot of time and energy at the expense of the ideals pursued and projects undertaken, and has a demoralising effect on individual groups and on the movements they are involved in. Open Organizations is one of many initiatives that attempt to propose solutions to this problem. It is focused on elaborating a concrete framework for action.

(I) TASK (Goals)

The Open Organizations project:

1. aims to produce a repository of knowledge about an interrelated and defined set of work processes based on political values, that organizations can implement now within the context of their work.
2. aims to make these processes always be functional i.e they will always describe processes that:
   1. can be carried out in present time by organization's participants
   2. can be measured (: how do we measure them? time? completion? we should state it.)
   3. are never fixed 'states' (: needs clarification)
3. will publishe repository on our web site, http://www.open-organizations.org
4. will use Creative Commons Attribution-NonCommercial-ShareAlike License
5. repository will include:
   1. The Open Organizations Framework - a catalogue of recommendations containing clear and practical implementation instructions for organizations to follow.
   2. The Open Organizations Conditions - a set of recommendations containing explanations of social conditions neccessary for the existence of open organizations and instructions for their implementations.
   3. Supporting Documents - further explanations and justifications for the framework's elements; placing it in a historical, philosophical or other context; relating it to other projects; reporting on its use.
   4. The Open Organizations Catalogue - catalogue of existing and past organizational practices (inclusing their critique) used for political values consistent with ours. A better world will not be invented from scratch; it will probably be built largely from what people already do and have done. However, existing practices must be adapted, and sometimes new ones must be created.
6. will explain why it is plausible whenever proposing
7. will continually investigate the framework's Conditions, i.e. the conditions that determine whether implementations of our recommendations:
   1. are possible
   2. to what extent
   3. by which kinds of organizations
8. will base its recommendations mainly on practice, according to the understanding that theory and practice rely on each other.
9. whenever possible, we will help organizations adapt suitable processes to their needs.
10. will carry out and maintain all the Processes and Rules that define an Open Organization.
11. will aim to make our particular implementations of these elements - and our varying degrees of success or failure with them - clearly visible and measurable:
    1. by viewing the organization and content of the Open Organizations website
    2. by reading our mailing list communications, http://lists.socialtools.net/wws/info/openorg-dev , where our ongoing working practices can be followed

---

(II) Participation

1. There is no formal membership in the project
2. Participation is open to all.
3. The Open Organizations web site will be an open 'Wiki', allowing all registered users (anyone can register) to modify any page. However, certain changes must be approved by the O-O Development working group before they can be made. (See "Decision-making" below).

---

(III) Decision-making

Any addition or change to the Framework (other than minor corrections of obvious errors) requires a collective decision.

a) Authoritative decision making place (location)

All collective decisions are made by "rough consensus" on the openorg-dev mailing list.

b) Method: Rough consensus

"We reject kings, presidents and voting. We believe in rough consensus and running code." David Clark, MIT

It can be difficult to gauge the level of consensus on a mailing list. Note that 51% of the group does not qualify as "rough consensus" and 99% is better than rough.

1. The views of active contributors (i.e. people who regularly contribute to texts on the project's web site) generally carry more weight than those of occasional contributors or non-contributors.
2. In order to gauge the level of consensus, the author of a proposal should state what they believe to be the consensus view, and request comments from the list about the stated conclusion.
3. Consensus is calibrated to the circumstances. An example to explain what is meant is:

If a group of 20 people are in danger of being shot dead by gunmen, a decision for the group on how to try to escape the gunfire will have to be made by a certain deadline and not necessarily can everyone be completely 'happy' with the decision - because otherwise they might all lose their lives. Consensus, in these circumstances: the rougher the better.

c) Rules

• <1> Decision-making about changes to the framework (and blocking of a decision) can only be made by those people who agree to personally maintain the rules of this charter and who are doing implementation work on the project. [ maybe we can have a legal "Yes, I agree to charter" button on the "HOW TO CONTRIBUTE" page?] Because the project has a theoretical base as well as a functional one, researching and discussing on the mailing list is essential, and valuable, but is not considered implementation work.

• <2> definition of implementation work here (we had it in the past)

• <3> Consensus means that a large majority consent to a decision. It doesn't necessarily mean that all or even most of them agree with it. In any group of people working together, it is not always possible to get what you want. Sometimes it makes sense to consent to a decision that you disagree with, because the disagreement is not important enough to justify jeopardising the cohesion of the group. This implies mutual trust: you know that when it is really important, you will be able to insist on something, and if possible, others will consent to it even if they disagree.

• <4> A decision can ONLY be blocked:
  1. if there is an objection that the decision would contradict an already existing Process or Functional Rule as defined in this charter
  2. if it would endanger the existence of this project.
  3. if political values, as interpreted by group consensus, are put in danger or not respected. In this case, a) doesn't apply and any Processes and Functional Rules that were found not to be consistent with political values must be amdended first - decisions can wait. This is considered an extreme case.
  4. or for any other reason, but some way to actually continue practically with the subject of the decision MUST be proposed at the same time as the 'block', eg amendments, improvements, substitution, alternative solution(s) etc.

• <5> All of the Functional Rules of an Open Organization must be applied to decision-making including all discussion towards it.

• <6> There are two kinds of decision-making:
  1. Decisions falling within a mandate that has been granted to a delegate (a person or group) by a constituency (typically the Open Organizations project as a whole). A mandate specifies types of decisions that the delegate can take without consulting the constituency first. Summaries of such decisions must be published after they have been taken. For example, they might involve details considered too small to interest the constituency.
  2. Decisions not falling within a mandate. These must be submitted as proposals and must gain a consensus before they are taken. In general, it is best for discussion to be published (e.g. by carrying it out via email), but this is not always feasible. Discussion can therefore take place in whatever medium the participants prefer (email, online chats, telephone conversations, in-person meetings). If a major disagreement is resolved during a discussion, a summary of the disagreement and how it was resolved must be published. If others want more detail about discussions, they can participate in them, ask for them to be carried out in a publishable medium (e.g. online chats) if possible, or ask for summaries of them to be published.

• <7> Sometimes privacy is needed in discussions, e.g. because personal matters are at stake, or because the discussion has become highly emotional and its emotionally harmful effects would be amplified by making it public. The need for privacy in these cases follows from the second political value. If others want to verify the need for privacy, or make sure that everything that should be made public is being made public, they can find a person trusted by everyone involved, who will act as Privacy Mediator. A Privacy Mediator observes private discussions and reports (without divulging the content of those discussions) on whether privacy is justified, and whether summaries should be published of any elements of the private discussions (according to point (b) above). If the Privacy Mediator disagrees on these points with the people having the private discussion, the matter must be settled by consensus, again following the second political value.

read, revise, include concept here and referr to wikipedia - http://en.wikipedia.org/wiki/Radical_transparency (this is a practice that we know well from indymedia, that wikipedia does well to start with, but fails to define well in few aspects. i'd like to revise this on wikipedia and then use it).

---

(IV) Exclusion from the project

a) consitent incosistency in carrying out commitments made

1. It is essential to commit oneself only to those tasks that one can actually carry out. Failure to do so (committing, but not carrying out) more than twice in a row, can mean, if requested by anyone, exclusion of that person from further work (only) on that task he/she is currently working on. That is, only being consistently inconsistent excludes.
2. Letting the other contributors know as soon as he/she knows that he/she will not be able to carry out the work he/she committed to do is a requirement.

b) disruptive behaviour

what is group's progress? what constitutes disruption of it?

1. Occasionally someone may engage in behaviour on the mailing list which disrupts the group's progress. In these cases, others should attempt to discourage the behaviour in private communication with the offending individual. If the problem persists, as a last resort and after explicit warnings, the group may choose to block the ability of the offending individual to post to the mailing list or otherwise participate in the project.

---

(V) Mediation

1. If discussions become bogged down or divisive, the task will be assigned to one participant that the group perceives as relatively impartial. That person's job is to oversee the nature, rather than the content, of participant interactions. That is, they will attend to the style of the discussion and the order in which topics are discussed, rather than making direct contributions themselves.

read and consider Mediation Vs Arbitration

---

(VI) Language

a) working language

1. The project's main working language is English.
2. Every effort will be made to facilitate translations of the web site (particularly the Framework) into other languages.
3. Messages may be posted on the mailing list in another language, if a participant has agreed in advance to post English summaries of posts in that language.

b) style and vocabulary

As far as possible, the Framework will be written in a clear, straightforward style, using ordinary words, in order to make it accessible to a wide audience and easy to translate into other languages.

c) supporting documentions

It is permissible to use specialized vocabularly and a more academic style in Supporting Documents, but clarity and ease of translation will still be valued.

d) long messages

When posting a long message on the mailing list, it is advisable to include a short summary at the top.

---

(VII) Releases

1. The project will work towards a "version 1.0" release of the Framework, and will make regular releases thereafter.
2. Subsequent releases will occur roughly every six months.
3. A Release Manager will be chosen to coordinate each release.
4. The Release Manager's job will be to (coordinate):
   1. set a date for the release, and a cutoff date for changes intended for the release.
   2. choose, after the cutoff date, which texts to include in the release. Each text chosen will be a specific version of a document on the web site. This choice will be based on an assessment (taking the group's consensus into account) about which texts are ready to be used by organizations.
   3. update the web site so that it is easy to find the texts included in the release.

---

(VIII) Delegation

If a delegate is needed to represent the project for a particular purpose (such as a meeting with delegates from other projects):

1. the group may chose delegate by consensus for specific purpose only.
2. anyone may voluteer and act as a delegate unless their doing so is blocked as allowed for in (III)
3. the delegate may not make any commitments on behalf of the group unless they have been given a specific mandate to do so by a consensus decision
4. the delegate may be recalled at any time by a consensus decision.

---

(IX) Amendments to this Charter

This charter is expected to evolve in small steps over time, and will come up for optional large review once every year.

1. on 9 June each year (the anniversary of the creation of the openorg-dev mailing list), a discussion will be started in which participants will raise issues about the charter and suggest amendments.
2. amendments require a collective decision, using the same process that is used for changes to the Framework.

---

This work is licensed under a Creative Commons Licence. To contact us, please use the openorg-dev mailing list.

---