Governance

Governance

To use the Governance in your community/collective/organization/project, copy the document as-is and:

• Replace all {} mentions with what is written inside.
• Add your own information in the sections marked with “—– —––”
• Add, edit or delete to any part of the document so that it fits your community’s governance.

The Governance document may be updated again in the future, please make sure you remember the version you copied.

Decision making

To use the Governance in your community/collective/organization/project, copy the document as-is and:

• Replace all {} mentions with what is written inside.
• Add, edit or delete to any part of the document so that it fits your community’s needs and culture.

The Decision Making document may be updated again in the future, please make sure you remember the version you copied.

Examples

The Decision making document is designed to adapt from communities of 2-3 people to organizations, offline-online and synchronous-asynchronous. All these usecases are covered.

As wrote in the Decision making documents, not all decision making steps have to be done by every group or community, and they don’t have to be done in order. The document aims to describe the core decision making process that should be followed and any criteria or modifications specific to a circle’s/project’s/community’s usecase can be added in an extra document or added directly to the current one. Some example structures are given below.

Note that in all example structures it is up to each community to decide how the facilitator role is decided, with what criteria/restrictions and provide support/education for them. The Cooperative Development Guidelines have a Facilitator Handbook document and also have the Circle Structure document that complement the Decision Making document. You are encouraged to use them (when you see fit) if you don’t have a structure for your community or to change/adapt your existing structure to something that fits more the spirit that the Decision Making document describes.

All the examples assume that the community has already decided how the facilitator role is filled and a structure for the community/group(s) that makes decisions. If the community is doing synchronous meetings see also the Synchronous meeting guide document. Documents for offline communities will be provided also by the Cooperative Development Guidelines at some point in the future.

1. There is a standards community (the structure of said community does not matter for this example) that wants to accepts RFC’s/specifications of some kind.

They have two documents to accept or reject specifications.

• A document that defines the criteria to accept the specification itself. These can be syntax restrictions, restrictions on compatibility, requirments that it has multiple implementations, etc.
• The decision making document edited to mention in the objections section that any specification can be rejected if it fails to fullfill the above criteria.

After this the group responsible for accepting specifications can use the Decision Making steps marked with the “[Decision]” tag as they are written in this document to decide on new or changed specifications.

2. A small software project with less than 3-4 regular contributors wants to decide how to accept contributions to the project.

The community has two documents.

• The Contributor Guidelines that defines the criteria to contribute. The Cooperative Development Guidelines doesn’t yet have a Contributor Guidelines template but will have one in the future.
• The decision making document.

For smaller changes its not worth it to go through the whole decision making process. Instead the maintainers can decide asynchronously to approve the change either immediately or after a short discussion.

For larger contributions where it requires multiple reviews, architecture design and collaboration with the contributor to meet what the maintainers want (and possible design decisions to fit the codebase), a person should be picked to be the “bridge” between the maintainers and contributor. This is done to create a consistent review process instead of the contributor having multiple parallel convos of convincing/discussing with the maintainers or the maintainers becoming lost of the current status and the requirments of the contribution. How the role is picked is up to the group, a process to decide for the role is in the Circle Structure document under the Role selection section, should you want to use it.

It is beneficial in this case to go through all the steps of the Decision Making process either asynchronously or synchronously to make sure the maintainers and the contributor are in the same page and neither party is feeling drained by the interaction. The facilitator the decision making document mentions, can be any maintainer that is organizing the discussion, or the same person that is the bridge between the contributor and the maintainers.

Note that in the future Cooperative Development Guidelines will have much more to say about how to organize the development to make it inclusive, more collaborative and less draining but these documents have not yet been written.

3. A software project is at the stage where people are starting to use it and report issues/feature requests to it.

A big problem that arises as a software project is starting to get used, contributed to and recommended by people, is the disconnect between:

• the people that contribute code. They feel like it takes too long for anything to happen or the criteria for code acceptance are too high.
• the maintainers of the project. They are isolated and feel their efforts are not recognized or the tradeoffs they are taking during development are not seen.
• the people that contribute non-code. This can be testing, translations, interface designers, etc. They feel like their suggestions/contributions are not heard or dismissed and their needs are not accomodated.
• the people that form the community around the software. These are forums, support rooms, opening issues and feature requests etc. They feel like they are not heard and their opinions don’t matter. People that are not part of the rooms regularly (or at all) feel less valued compared to people that can be there all the time.
• the moderators and/or mediation circle/team. They feel like community safety is an afterthought compared to writing code and they don’t have the tools they need to protect the community.
• the people that use the software but do not interact with it

The decision making process described in this document can help in bringing about a new approach to developing software that can lessen the problems described. The maintainer(s) of the project can opt to create a small group of people with delegates from the community, one person from each area above (except the last one since they are not in the spaces of the project), of people that they trust. The Role Selection process under the Community-wide section can also be used to select the participants.

By creating this group and using the Decision Making document to decide, the project can build a collaborative approach to development based on cooperation. This is done by giving decision making power and self determination to people that participate in the different aspects of developing or using the software, istead of only developers - people that can code as it is traditionally done. By doing that transparency/open communication are build and it becomes more clear what are each group’s priorities, tradeoffs and capabilities are as well as current in-progress tasks. It also helps avoid “suprising” situations where a version or a feature is released only to find out that it is broken/badly designed or it was never wanted by the community in the first place.

How to have a healthy community is out of scope in this example and a separate document will be written. In short having a Code of Conduct, and moderators so that the maintainers don’t burn out is some of the vital parts in making sure everybody feels welcome to join and participate. A mediation team is also recommended to be created for any serious reports that may come up. The Cooperative Development Guidelines aim to be a practical guide and blueprint in creating and maintaining such communities.

Because not all documents have been written this example is missing details. Follow development of the Cooperative Development Guidelines and join our rooms if you are interested in discussing with us or contributing.

4. A server hosting a community of some kind (chat, microblogging, etc.).

Social communities hosted by small servers are traditionally a thankless effort relying on donations, and people using them rarely know the person that is running them or care what happens to it. If we are to give a real alternative to centralized services (where its expected some hierachical/capitalist company will maintain the server without any involvement from people), then we need to change how we structure and interact in such communities in the first place.

Similar to the software project example, this one is also going to be incomplete due to the in-progress nature of the Cooperative Development Guidelines. A circle structure and a Cross Community Circle would be some of the things to look for.

Some of the problems encountered here are:

• The person/people maintaining the server are expected to handle not only the technical side, but also the moderation of the server, the website and outreach among other things
• People registered with the server often lack any kind of knowledge into what happens with the server, so they assume its all working great (until it isn’t) or the server is always online
• Moderation is seen as a service that is provided by the server without any kind of help or effort from people using the server
• The only option for somebody to contribute is often to donate money
• There is an implicit assumption of the person/people maintaining the server providing an equivalent service to the capitalist companies, and a similar way of operating

The Decision Making process described in this document can be the core of a more inclusive server community built around shared values and caring for the shared space together. Moderators, people using the server, server maintainers and people doing outreach among other groups, can decide together in a safe space with consent on what happens to the server and what needs to be prioritized or what any other concerns of each group. This way power is shared instead of being held by one or a few people and there is transparecy, sharing of responsibilities and inclusivity.