Cooperative Development Guidelines

Templates, guides and values to structure our spaces by-and-for us, the community, with a dynamic structure (without hierarchies or voting) and participatory processes (plurality, diversity, platforming, etc.)

The core structure and processes (in the Foundation Folder) are community agnostic and can be used with any community of reasonable size or structure. Guides on how to adopt it are inside the Adoption folder (TBD.) and reading material for the Community are in the Community Folder (TBD.)

We are also writing an evolution of the Free Software Denifition and the Open Source Definition with the aims of:

giving power to people using the software (not just developers) with participatory development
code of ethics (privacy, accessibility, permacomputing, consent, etc.) and a guide to write software that can be used and improved by others (reproducibility, easy building process, etc.)
Ubuntu - “I am because we are”. Meaning we are not individual “islands” but instead we all have responsibilities and obligations to each other so that we can all build software we like together. Each of us can help make the other person safe and comfortable in our communities.
Pave the way to a new Digital Commons where there is no single upstream (“gatekeeper”), rights and obligations to be part of the Digital Commons and a diverse ecosystem of software variants that are customized for purpose.

Communities that use these guidelines

The JoinJabber Collective
The Applesauce project (that these guidelines orginated from)
The Bechamel Guix Collective
The Munakoiso XMPP Project
The Queer Spark collective
The Convo XMPP project
The muchrooms XMPP project
The Jabboratory Collective

Document Metadata

All documents have on top the metadata that are defined in the RFC template in the Governance document. This is done because all documents double as RFCs, and we follow our own guidelines, which means the Cooperative Development Guidelines are “self-hosted”.

We follow the template Code of Conduct that is here for everybody else to use.

Contact

Vojkruco Lounge

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.

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.

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.

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.

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.

Decision Making

Decision Making Quick Reference

For more expansive guide on each step see the Decision Making Steps document.

When Crafting a proposal from the beginning

[Exploration] Understanding the topic

Understand first the topic before sharing opinions/ideas or deciding what to do. Include the community and any other knowledgable/affected groups or people.

Most importantly: Should we do anything about this? We may choose not to if:

The circle lacks the experience, diversity, knowledge to act effectively (its okay to say “I/We do not know”)
The act of doing may bring more constraints than it actually solves (structural, technical, social)
It may bring more complexity than the circle or the community can handle (structural, technical, social)
The circle may need more research to increase knowledge and outreach to people affected before deciding they can do something
It may bring the circle in a position where it forces its culture and subjective morality on others. See White Savior and Charity. In these cases the circle should opt for empowering the affected people to be able to do self-determination independently and help alleviate any roadblocks, hierarchies or structural problems instead.

See also the Not Doing page and Observe First page in the permacomputing principles.

What do we need to know for a proposal to happen? What should we be mindful of, avoid or give special attention to?

Share whatever idea comes to you, realistic or not. We want as much plurality and diversity of ideas as possible.

[Synthesis] Proposal forming

Combine as many ideas as you can into one proposal. All feedback (concerns/ideas/objections/suggestions) is heard and added to the proposal by modifying the proposal. (See the Decision Making Steps document for more).

Don’t bother with details yet since the proposal may change drastically during public feedback period, focus on general ideas.

Deciding on a written proposal

[Decision] Present the proposal

Present the proposal to the circle in clear-easy to understand language.

[Decision] Clarifying Questions

Give people time to ask questions and understand the proposal. No questions about why or how are allowed, only questions to the understand the proposal at hand.

[Decision] Quick reactions round

Speak your mind freely about what you think of the proposal. This doesn’t have to be about your stance on the proposal, just general thoughts and feelings.

The facilitator asks everybody to consent to the proposal or share their concerns. Incorporate concerns, but if the proposal changes too much the steps reset back to the “[Decision] Present the proposal” step. If Objections are discovered see Objections document.

A concern or potential objection IS an objection if:

it compromises a core value of {Community name} written in the Code of Conduct, Governance or any other Governance documents and Community-wide agreements. This includes any additional guidelines and frameworks that the community follows (Cooperative Software Guidelines, Permacomputing Guidelines, Consentful Tech, Security Guidelines etc.)
the Circle document and/or the Circle agreement (if it exists), See the Circles Structure document for these documents.
compromise the domain that the circle has the power to act in. For example the translations circle can not decide to shut down the spanish translations circle unilaterally or the website circle can’t decide what happens on the server.
compromise the aim of the circle, aims are written in the Circle Document and they are the foundational goals and values of a circle.
contradicts/goes against an earlier RFC that is still active or duplicates/obsoletes an RFC implicitly or explicitly (if the proposal is an RFC).

A concern or potential objection is NOT an objection if:

the circle agrees that it does not fulfill any of the above criteria
it has been decided by the circle that it was accounted for or has been integrated into the proposal

Decision Making steps

The following document describes the process and steps we use to make decisions. Not all of these have to be followed and they don’t have to be done in order. Some steps (or all of them) may also be done asynchronously and with or without rounds. Or any variation thereof depending on the context and the culture they are applied in (offline/online, good/bad connectivity, etc.). On how to do these steps in a meeting (and a general meeting guide) see the Synchronous meeting guide document.

Each step has a tag, that corresponds to a specific aspect of decision making, in the title inside square brackets “[]”. These tags are:

exploration is gathering ideas, feedback and constraints to create a proposal, in this case the “Understanding the topic”, “Share considerations on the topic” and “Share ideas” steps are done.
synthesis is creating a proposal, in this case the facilitator should follow from the “Proposal forming” step.
review is for reviewing proposals, when their date of next review has come, and see if the proposal is still working or if it needs changes. (the “[Review] Review an existing proposal” step below under the “[Decision] Consent”)
decision is giving feedback to a proposal and making a decision, in this case the steps starting from “Present the proposal” shall be followed.

Each topic’s tag is decided by the facilitator, the logbook keeper, the coordinator and the proposal author (or the roles that exist at the time in the circle).

[Exploration] Understanding the topic

A topic may be brought to the attention of the circle by anybody (individual or group (formal or informal - state recognized or not)) from inside or outside the circle.

The circle is expected to actively gather wide feedback about the topic both relating to the questions below, but also about constraints, ideas, and efforts that have already been made (if any) by others. The more diverse feedback and experiences we gather the better the proposal will become, not everybody that is affected or can contribute their experiences is in our spaces. We should make an effort to reach out to people that are not here and empathise/advocate for the people that cannot contribute or make their voices heard.

Some list of examples for gathering feedback (that is not exhaustive):

asking a more general circle for input, through delegates. The more general circle may have a higher level understanding since more circles and domains are involved.
asking a more domain specific circle that is a subset of the current circle through their delegates.
creating an temporary circle together with people affected and deciding by consent (thus getting them involved directly in the decision making process).
asking specific people for input that may be knowledgable on the topic.
ask for feedback from parts or the whole collective/organization/community.

It is important before proposing ideas to take time to understand the topic we are trying to solve and why it exists. The aim is for everybody by the end of this step to be able to answer the following questions:

What is the problem we are trying to solve?
Why does this problem exist?/ Why does this idea need to exist?
What is the impact of this problem?/ What is the impact of us doing something?
Who is affected by this?
Can we potentially do anything about this?
Is this our responsibility? There may be a case where the current circle is not able to make decisions for the domain the topic applies to, in this case the circle should forward the topic to the appropriate circle.

The circle will be ultimately responsible for this decision so the topic should be presented in a way that is understood by everybody or that allows people to understand enough to delegate the solution to somebody they trust.

There may be cases where a person from the circle may phrase a potential objection towards any action for a topic, warning the circle of unintended consequences. In that case the facilitator should refer to the Objections document and see if the potential objection is an objection. If it is, then the circle may decide to do nothing. Its important for the circle (and individuals in the circle) to realize that sometimes not doing anything, may be the best option for a topic. This can happen because:

The circle lacks the experience, diversity, knowledge to act effectively (its okay to say “I/We do not know”)
The act of doing may bring more constraints than it actually solves (structural, technical, social)
It may bring more complexity than the circle or the community can handle (structural, technical, social)
The circle may need more research to increase knowledge and outreach to people affected before deciding they can do something
It may bring the circle in a position where it forces its culture and subjective morality on others. See White Savior and Charity. In these cases the circle should opt for empowering the affected people to be able to do self-determination independently and help alleviate any roadblocks, hierarchies or structural problems instead.

See also the Not Doing page and the Observe First page in the permacomputing principles.

Before sharing ideas, the group needs to gather considerations around a topic. These are:

The priorities that are important for a proposal to have, so that the group can focus on what is important.
The specific issue(s) that the proposal should address.
The concerns and harmful consequences (potential objections) that the group should be wary of while drafting the proposal.
The different people and groups affected by the proposal that should be participating in the drafting of the proposal.
The knowledge and feelings of everybody in the circle around the topic.

This way we make sure everybody is on the same page and agrees what a proposal should and should not address.

After everybody has understood the topic and they have shared their perspectives, its time to share ideas around what a proposal or action would look like. All ideas should be informed from the steps that came before (understanding the topic and sharing of views around the topic) and any feedback that was gathered from outside the circle. The ideas can contradict each other, and they don’t need to be phrased as a concrete plan, but members should weigh the pros and cons of each idea. Concrete steps on how to take action and/or create a proposal will be taken later.

The facilitator should guide the discussion around people’s needs and concerns instead of debates. This is done by asking questions in a way that helps people phrase their preferences well, making it clear that is the step where we just share ideas and not a “realistic”, “final” or “concrete” step, and self-reflect on their ideas and opinions.

[Synthesis] Proposal forming

This step is for agenda items with the goal of “synthesis” and doesn’t have to be done by the whole circle. The RFC template can be used from the governance document if desired.

Sometimes it may be desirable to craft a proposal without involving the whole circle. This may be done for example because a person is more knowledgable, the proposal requires research or feedback from others or the circle doesn’t have enough time. Good proposals capture not only the entire spectrum of opinions and feedback that was shared in the circle but also the feedback and the opinions that were shared outside of the circle.

Not all ideas need to be followed, but all the feedback (concerns/ideas/objections/suggestions) should be added to the proposal. This can be done for example by:

Taking different aspects of each idea and combining them (it is up to the facilitator to guide the process so everybody is heard and satisfied with the outcome)
Clarifying what is the result/impact we expect by implementing the proposal, and how to measure that
Making the date of the next review (where we check if the proposal works), sooner or later
Seeing if any argument is an objection, objections help bring the attention of the group to a proposal that may have harmful consequences. (for more information see the Objections section in this document)

Note that this step (Synthesis) is about creating the proposal around general - high-level agreements/ideas that the circle have (and any people/groups affected). The facilitator should remind the group not to stress over details at this time because the proposal can (and probably will) change after announcing it publicly for feedback by the community and people/groups affected. For the steps to go over the proposal in detail (and reach consensus on the proposal) the circle will continue after sufficient time has passed to gather feedback.

It is important to be aware and honest what is just a preference (it would be nice to have but its not critical), an opinion (I like this solution personally), a concern (I am worried about this proposal and would like some assurances) and a potential objection (this proposal undermines fundamental values of the circle or our community (see the “Check if it is an objection” step in the Objections Document) and should not happen). Try to remember the important issues we try to solve and avoid from the exploration steps. We should do what is best not just for us, but also the circle and the overall community, by putting our ego aside.

We aim for equity not equality. As already mentioned not all opinions are of equal weight due to experience, privilege, impact, status or knowledge. Individuals and groups (formal or informal - state recognized or not) that are directly affected by this proposal should be involved directly without waiting for them to see the proposal. This can be done by contacting them directly and asking for their opinion, include them in decision making (with delegates), involving them in proposal drafts and taking their concerns and potential objections (if any) seriously.

After the proposal have been synthesized adequate time is left for individuals and groups (from inside and outside the circle) to react to the proposal and it is shared with the wider community for feedback.

[Decision] Present the proposal

The first step to make a decision about a Proposal is to present it to the circle. This is done because even if the proposal was formed by the circle (in the synthesis step), the feedback that was taken from the community has most likely changed the proposal. Presenting it helps get everybody on the same page and see what changed so they can give their informed consent.

The presentation should be understandable by all members to a sufficient enough degree that they can give their consent to the proposal, by avoiding technical jargon and adapting the presentation to the audience’s knowledge and experiences. All materials and documents of the presentation (including the RFC if applicable) should be available before and after the presentation, for all people to read it at their discretion.

[Decision] Clarifying Questions

It is important before phrasing any opinions about a proposal that everybody understands what the proposal is and take the time to resolve any misunderstandings about it. Note that while members can ask “What does this mean”, questioning “why” or “how” is not done in this step. The focus is only to understand what is written in the proposal without any judgment.

The facilitator needs to be able to guide the discussion towards understanding the proposal instead of commenting on the proposal or disagreeing with it.

This step follows with the basic principle of the Code of Conduct that says “Assume good faith”. All members should assume (unless explicitly told otherwise) that the person presenting the proposal has researched the topic, knows about the topic and cares about the well being of the group and the community’s. A proposal should be approached from a place of curiosity towards a topic that the members were potentially not aware of before the proposal was presented.

[Decision] Quick reactions round

Now that everybody has a clear understanding of what the proposal is about, its time to hear everybody’s thoughts and feelings on the proposal. These can be positive, concerns, or anything else around the proposal. They also can be just general thoughts about the proposal. Communities thrive on feelings of gratitude, appreciation and encouragement. Take the time to appreciate the effort and care the person took to write and present the proposal to the circle.

This step may surface concerns or potential objections with the proposal (the objections will be identified later), but it also helps in seeing the proposal through other people’s perspective. This step is meant to be short so people should only give a short statement on what they think or feel about the proposal and they don’t have to say what the potential objection is, or if they consent to the proposal. Longer form discussions will happen at the “Consent Round” step.

Avoiding discussions and replies on what each person says, helps keep the discussion focused and creates an environment where everybody is encouraged to share without being afraid they will have to “justify” their position or be prepared to defend themselves at a moment’s notice.

If there are too many concerns or objections it can be a sign that the proposal needs to go back to the exploration steps and/or time for more feedback before going through the decision making process again.

Now that all the different perspectives on the proposal have been voiced, its time to decide on the proposal. As a community we want to enable people to contribute and create change while also stopping harmful change from taking place. This is done by altering the proposal according to feedback and concerns (as documented in the Synthesis step, the current step and the Integrating Objections step).

Everybody voices their opinions around the proposal and the facilitator collects all the feedback said by members in three different aspects:

Concerns: Concerns are possibly harmful effects that a proposal may have if it is implemented. The author and circle should listen to the concern, understand if it is a concern or an objection and decide how to integrate it into the proposal.
Potential objections: Objections are concerns that can be defined against a specific place in the Governance or Circle documents. The facilitator guides the circle to resolve each potential objection separately, by using the objection process. Refer to the Objections document.
Small corrections: These can be typos, wording, grammar, or other small corrections to the proposal that help clarify or correct what is already written.

Everybody is encouraged to voice concerns or potential objections even if they are not sure which of the two it is or do not know exactly what their concern is. It is up to the circle to discuss with the person voicing the concern and understand what it is about. If during the discussion of a concern it is discovered that it may fulfill the criteria to be an objection (see the Objections document), then the circle should follow the objection process instead for that concern.

They should also try to give platform to people who may be more quiet or not as sure and see that nobody dominates the discussion (see also the facilitation, the values and the principles sections). As it has been written before, the circle is part of a whole and has a responsibility to the people in {Community Name}, to people outside of {Community Name}, to the wider community and to people that don’t share their expertise. Not everybody will be happy with the proposal, but everybody’s opinion will be respected and considered (whether in the circle or not).

As wrote in the “Safe enough to try” principle (in the Values of Decision Making document), the facilitator doesn’t ask in this step if everybody agrees (as done usually in consesus). Instead they ask “Is this proposal safe enough to try? Does anybody have any potential objections to the proposal going forward?” If nobody has a potential objection (see the objections section on how to identify them), then after all the feedback has been gathered and acted on, they ask for consent and the facilitator makes it clear that the proposal has passed. The only options at this round is “consent” or “object”. The idea is that if somebody doesn’t want to consent then there are concerns that haven’t been voiced. See also the “Accountability” and “Plurality” sections under “Values of Consensus” section.

Consent here contrary to voting or traditional consensus does NOT mean that somebody agrees with the proposal. When the facilitator asks “Is this proposal safe enough to try? Does anybody have any potential objections to the proposal going forward?” it means:

Is this proposal safe enough to try? Does it harm/go against the aims of the Circle/{Community Name}, or goes against the values and principles outlined in the Circle Documents/agreement, Governance or Code of Conduct?
Do we trust that the person/people/group that put the proposal forward are acting in good faith and want the best for {Community name}/the circle?
Do we trust that the decision making process was followed and that all objections and feedback was addressed?

The circle should take care to listen to delegates from other circles or from outside of {Community Name}. Listening to their concerns is vital to create good proposals and build trust. If the circle makes a decision and the community is angry or disappointed that is a sign the circle failed to describe the thought-process and constraints that led them to the decision or get enough feedback and involve the people affected.

Big alterations to the proposal, like for example a different approach or significantly altering a large amount of the proposal, its implementation or its scope, should not be done here. Instead the facilitator can start a process round to decide what to do next. The outcome of the process round could be for example getting the proposal back to the exploration phase, or involve people that feel strongly about the proposal to propose a new version of it with the author or something else. Note that this does not block the proposal from going forward unless these changes are part of an objection (see the objections section on what are objections).

This helps create a culture that:

respects the time and effort that went into each proposal while encouraging change. all proposals are accepted unless they are blocked by objections.
respects the concern and feelings of people that are affected by a proposal and enables them to change it and propose a new version of it.

[Review] Review an existing RFC

RFCs are reviewed periodically by the circle to make sure they are still working as intended and they are not obsolete or need changes. This helps keep the amount of active RFCs low, as current/well-written as possible, and also helps with self-reflection around what works and what doesn’t.

When the “date-of-next-review” time that has been agreed has come (written in the RFC metadata), the RFC is added to the agenda with the tag [Review]. The facilitator shall guide the circle to decide whether the RFC is still working as intended or if it needs changes or is obsolete. The process used is the same as the decision making process starting from the “[Decision] Present the proposal” step.

If it is obsolete, it shall be archived and be no longer in use. The procedure to archive an RFC is up to each circle, but the RFC should still be visible for historical purposes. If the RFC is still good the field “date-of-next-review” shall be changed to the next time the proposal is reviewed.

Passing

Passing is a deliberate choice that a circle member can make in two circumstances:

When doing rounds or asking people of their opinions at any step of the Decision making process (or during a meeting in general). Passing means that other people have already said what you wanted to say and there is nothing more to add. This shows trust in the group and self-confidence.
When the circle can decide to have a meeting about a decision or when a person doesn’t have time to get involved in a decision making process. In these cases the person can either work with the facilitator to change the timeline of the decision/time of the meeting or they may choose to “pass”. Passing means that they will be written in the minutes as “{person} is passing”. Any kind of feedback on a specific proposal will not be taken into account and the proposal will not be affected by their feedback. The facilitator may choose to write down their feedback in the minutes for transparency reasons.

Note that passing doesn’t mean a person can “opt-out” of being co-responsible for a proposal. All members of a circle are still co-responsible whether they pass or not, if a person passes they just choose to be responsible but without voicing their feedback or influencing the proposal in anyway. It is up to the Circle to decide what to do if a member passes consistently a lot of proposals or chooses to not help/be co-responsible for them.

See the “Why are the only choices for a decision consent and object?” section in the Values of Decision Making document on why “passing” is not anything more.

[Decision] Proposal implementation

Now that a proposal has been decided, the circle decides how the proposal should be implemented, picks a “date-of-next-review” (if the proposal is an RFC) and picks a person to implement the proposal. A detailed action plan to complete the proposal is key to make sure that the time the circle gave to write and/or decide the proposal wasn’t wasted and helps with motivation within the group. It also helps the coordinator later and helps with making the work of the circle transparent.

Sometimes this can be easy, for example the person that wrote the proposal wants to implement it, or a knowledgable person volunteers. There are times when its not that clear who is going to implement the proposal. Either a lot of people want to do it, or its not clear who should do the work. For these cases the circle can use the “Role Selection” process described in the Role Selection document.

Some questions that should be answered by this step (and recorded in the meeting minutes) are:

Who (or which people if there are more than one) will implement the proposal?
What work will be done by the person/people?
What is the timeline to implement the proposal?
What happens if they need help or don’t have time/spoons?
How can the group check that the work is taking place/has happened?
What is the date that was decided the RFC will be up for review again? (This is in case the proposal is an RFC from the Governance document)

Objections

Potential objections are phrased by a person in the circle, to warn for unintended or harmful consequences. This is done during exploration of a topic or when a proposal is decided, to bring up a perspective that the group may not have seen or considered. The well-known principle of “assume good faith” applies here. Any person voicing a concern or a potential objection is not an obstacle and it should not be assumed they want to block the proposal or stop the work the circle is doing. They want to see the proposal succeed just like everybody else, but they see ways that the proposal could better serve the community and fulfill its purpose.

As wrote in the “Plurality” section in the Values of Decision Making document, objections are not only encouraged/apreciated but actively sought and are important feedback during creating or consenting on a proposal. Without objections proposals would be either missing key feedback to make them effective or be harmful to the circle and/or the community.

Further reading on why this model is adopted see the sections “Safe enough to try” under Principles, “Plurality” and “Accountability” in the Values of Decision Making document and the “[Decision] Consent” step in the Decision Making Steps document.

Understand the objection

The first step in the objection process is to understand the potential objection.

The facilitator asks the person that phrased the potential objection to expand on their statement and say where they are coming from and why they see the proposal being harmful. They can also point out the exact place that the proposal will violate or do harm if they want, that is not required though.

The person that phrased the concern or potential objection may not know what the objection specifically is or be able to articulate it well enough for others to understand (due to emotions running high, language bariers or other reasons).

The circle does a round so that everybody can ask questions and share their thoughts around where the potential objection is coming from and the potential objection itself. It is up to the circle to do the work and find the underlying argument that the person phrasing the potential objection was trying to convey.

Check if it is an objection

After the objection is clear and everybody has understood it, it is time for the circle to decide if the potential objection is indeed an objection or not.

A concern or potential objection IS an objection if:

it compromises a core value of {Community name} written in the Code of Conduct, Governance or any other Governance documents and Community-wide agreements. This includes any additional guidelines and frameworks that the community follows (Cooperative Software Guidelines, Permacomputing Guidelines, Consentful Tech, Security Guidelines etc.)
the Circle document and/or the Circle agreement (if it exists), See the Circles Structure document for these documents.
compromise the domain that the circle has the power to act in. For example the translations circle can not decide to shut down the spanish translations circle unilaterally or the website circle can’t decide what happens on the server.
compromise the aim of the circle, aims are written in the Circle Document and they are the foundational goals and values of a circle.
contradicts/goes against an earlier RFC that is still active or duplicates/obsoletes an RFC implicitly or explicitly (if the proposal is an RFC).

A concern or potential objection is NOT an objection if:

the circle agrees that it does not fulfill any of the above criteria
it has been decided by the circle that it was accounted for or has been integrated into the proposal

If the circle decides together with the facilitator that the potential objection is indeed an objection, the members explore options to integrate the objection into the proposal (if possible), see the next step below.

If instead the circle decides it is not an objection then the facilitator asks the person that raised the potential objection, if they are satisfied or if they want to refine/rephrase/reframe their argument. If the person making the objection is satisfied or all the parts of the potential objection have been addressed the circle moves back to the “[Decision] Consent” step to continue the decision making process.

Explore options

To resolve an objection that was identified, the circle needs to either integrate it into the proposal or remove the proposal from being considered. Integrating the objection into the proposal is always preferable since it respects the time and effort of the person/people that made the proposal while also respecting the person/group that brought up the objection. Our aim with this step is: “Can we modify the proposal in a way that all members find it safe enough to try it?”

Some examples of integrating the objection can be:

changing some of the proposal (adding, removing, rephrasing, etc.)
shortening the “date-of-next-rewiew” field so that the circle can reflect on the proposal sooner. The review date can be as short as the circle deems appropriate so that the proposal is closely monitored for harm.
Adding additional criteria to the proposal to know when we have succeeded, in the “## How do we know we succeeded” field of the RFC template if the proposal is an RFC (see the Governance document). This can include metrics or effects that the circle needs to keep an eye on to measure the impact of the RFC. When a criteria has been reached the proposal can be changed or rendered inactive, this can happen either at the next review date or immediately after the criteria was reached, its up to the circle. Adding clear, transparent and specific criteria here is key to avoid ambiguity.
creating a new temporary circle (see the Circles Structure document) or pick a person to change or craft a new proposal
leaving some time for the circle to reflect on the objection and come back to the proposal or objection later
if the objection relates to a domain of a circle that may know more (for example the objection is about accessibility), ask the delegator (if they exist in the current circle) or approach the circle to ask for feedback
the objection may be not as significant compared to the potential benefits of the proposal or the effort of accounting for the objection is higher than just testing the proposal in action, so the circle may decide to do nothing

By integrating the objection the aim is to avoid getting stuck debating on a concern for a long time (and discourage people from participating or giving rise to “last person arguing wins” models). Instead it enables experimentation with new ideas and diversity of views provided the circle agrees its “safe enough to try”. It is always preferred to experiment and try to see how/if a proposal works in practise than endlessly debate about theoretical concerns that may never happen in practice. If any proposal turns out to be harmful the circle has transparent, documented and clear criteria for that (that have been reached/failed) so that it can be reverted easily.

Depending on how the circle decides to integrate the objection, different next steps can be decided to integrate it. After the objection has been integrated in a way that is good enough for all members, the circle moves back to the “[Decision] Consent” step to continue the decision making process.

Values of Decision Making

In {Community name} we are using Consensus decision making that has been heavily influenced by the Sociocracy way of decision making, the Seeds for Change collective and consensus decision making in general.

With this decision making process the aim is NOT elimination of power (elimination of power is not possible - whether conscious or unconsciously we all have and exercise power), it is not to make the whole process completely structureless so that its not clear what is decided/by who/when and it is not to sweep all biases and prejudices under the rug and be “apolitical” or “neutral” (that doesn’t exist either).

This Decision Making process aims to distribute power in the community and circles so that each person has self-determination but also respects the self determination of others. If the structure of a community is clear and everybody respects what is written, there is accountability, transparency and inclusivity on how to get involved and change things. All members advocate and speak up against injustices, self-relflect on their biases and commit to educate themselves on different experiences and cultures. We are embracing the fact that we do not know everything and we may be wrong, while acknowledging that we can’t leave our biases at the door (no one can). Instead of pretending they don’t exist (or hiding them), we put them out in the open, call them out and decostruct them collectively.

As wrote in the “[Decision] Consent” step above, the point of consent is for everybody to combine their ideas and come up with a proposal that covers as much (if not all) the feedback (ideas/opinions/concerns/objections) of the circle as possible. This is done by finding what each person can live with today (consent) and what is harmful for the circle or/and the community (concerns/objections). It is not the goal to find a proposal that everybody accepts (such a proposal doesn’t exist), or a proposal that finds the “middle-ground”. This will only serve to reduce diversity of opinions for the sake of finding an agreement.

Giving people a third (or fourth or fifth) choice, like abstain/agree with concerns/etc. was considered, but was rejected because:

people will be pushed to make that other choice so the group can “move on”
it will long-term widen divisions and contempt in the group. It will be seen as “You have an obligation to me because I let your proposal pass”, “I have sacrificed myself for the group by letting proposals pass”
there will be clear division of the group on each proposal, between the people that wanted the proposal (and agreed) and the people that made the other choice. This will lead to “I don’t have to work on the proposal because I never wanted it”, “I had concerns but I didn’t care to voice them because I don’t want to work on this anyway”, “This is your part of the group so I’m not going to help”.
there will be less effort to accommodate the needs of everybody because people are expected to “stand aside” or not care.

By having only these two choices, the group can build tolerance for different opinions, trust and respect for all members while encouraging participation.

Principles

Safe enough to try

We know and are embracing the fact that we (as {Community name} and individuals) do not know everything, either because we lack experience, time or both, and no proposal/decision will be perfect or last forever. That is why we do not seek to convince each other (agreements), push a person to “stand aside” or to be convinced something will work, instead we seek people that want to experiment, learn and self-reflect. Proposals are decided by concluding that: “This proposal looks safe enough to try, after seeing it in action we can roll it back or change it”. We do this by seeking and incorporating objections.

This is reflected also in how we ask for consent during decision making. Instead of asking for what everybody wants/if everybody agrees, we ask whether there are reasons not to go ahead and if everybody consents. Those reasons would take the form of an objection. For the definition of objections, how to test if an argument is a objection and how to integrate them in a proposal see Objections document.

Objections are encouraged (and actively sought as stated) and are important feedback that makes the circle aware of harmful or unintended consequences about a proposal. This is the complete opposite to some other consensus models where a block is seen as an obstacle to be fixed, or the forced rejection of a proposal by the group (because one person decided unilaterally to reject it).

This aims to solve a chronic issue in consensus (in the sense of: we “have to” agree) where decision making ends up either polarized between for/against or the people that want to do things end up being blocked from a minority of people just because they can block and as a consequence decision making power lies with the person that blocks. Some other benefits are:

Instead of competing with different proposals/ideas or being given the choice of for/against, we cooperate and integrate all feedback (concerns/objections/ideas/suggestions) into one proposal.
People feeling more safe to voice their opinions, because they know it will affect the proposal directly instead of having to create a whole separate proposal and advocate for it.
There is co-responsibility and no one is ignored since there are no “stand-aside”.

Participatory decisions

We are aware that not everybody can or wants to be part of decision making, and we practise participatory decision making to counter that (see also our Governance document and the Code of Conduct). Meritocracy/do-ocracy/volunteers (as used in tech where volunteers are doing whatever they want disregarding the community) is a dead-end that gives power to already established privileged groups. To create a healthy and diverse community we practise Participatory decision making to counter that.

Making decisions in a participatory way includes both seeking/including people that are affected/knowledgable and putting the needs of the community as a whole above the needs of us as individuals.

When forming proposals (see RFCs in the Governance document, if the proposal is an RFC) we actively seek and include people that are affected by said proposal and the wider community, in an effort to collect feedback and integrate it into the proposal. After the decision is taken we write in a document (inside the RFC if that template was used) why, how and what decision we took and publish it in a public place so that transparency and trust can be build. In this way we commit ourselves to listen and follow the needs and wishes of the circle/{Community name}/wider community while also listening to feedback across that spectrum.

This process helps bring transparency to the decision making process and how decisions are done. It also helps build a feedback-loop where people that are affected/knowledgable but not involved in the decision can change proposals directly or affect how things are done.

As written in the Governance document and the Code of Conduct), we (as {Community name} and as individuals) have responsibility to the people that can’t contribute in our area of expertise (because of knowledge, time or other reasons), or are not able yet to contribute, to give them platform and hear their feedback. We have a responsibility to take them into account and accommodate them. A community thrives on diversity of ideas, contributions, experiences and we recognize the imbalance of power that comes from people not having knowledge of all areas required to develop software or not have the ability or privilege to do it. We work on deconstructing all hierarchies and enabling people to be heard when we are in a position that we can do that.

Decentralized-autonomous decision making

We do not make decisions all together. We build trust with other circles that all the people affected will be heard and respected but not necessarily involved in decision making (outside of delegates). Instead we have circles that interact with each other and decide according to their domain they are responsible for. This makes it so:

People have more impact on decisions being made instead of in a bigger assembly where their feedback will get lost and only for/against positions matter.
Decisions are made by affected/knowledgable people, based on self-determination and direct action instead of trying to convince people that don’t care or that do not know about the topic.
Tighter circles (circles should not go above 10-13 members) that can be more familiar with each other, more empathetic and take more time to listen or deliberate.
Scalable while not compromising inclusivity. We can create as many circles as needed without having to resort to voting systems, restricting who decides, or making the decision just a yes/no choice.

While not everybody is involved in decision making, each circle has multiple ways to get feedback and people affected can influence what decisions are made. See also the “[Exploration] Understanding the topic” and the “[Decision] Consent Round” steps.

Values

Plurality

We welcome, encourage and actively seek different viewpoints and disagreements to deepen our understanding of a proposal and to see experiences outside of our purview. We acknowledge that we each of us has more or less privilege in society and that we all have different experiences and backgrounds that contribute to plurality.

To do that we use rounds (see the Facilitation Handbook Document), have a mediation team, have a Code of Conduct, participatory decision making (as noted in the participatory section above) and also have facilitators that guide the decision making process and structure the conversations. We cultivate a culture where all people have the space and the time to voice their ideas, needs and opinions, and nobody gets “tone-policed” or harrassed/bulied/shamed for speaking.

Consensus requires us to be open/honest about our needs and be clear about what is just a preference compared to a concern. We acknowledge that we will never get exactly what we want and we work to find shared ground with others in the circle where all of our shared needs are met. We can only arrive at good decisions/proposals through disagreements and sometimes conflict. Having conflicts and disagreements is a necessary part of consensus as not everybody has the same experiences, views or ideas.

Making decisions “quick”, “easy” and “unanimous” will result in pushing people “out of the way”, homogeneity, fear of speaking up/taking away expression and dominating of discussions by a few people. We acknowledge that by making decisions with plurality they are going to take longer to make, but that is a tradeoff that we are willing to make.

Plurality is lessened not only about conscious ways power is exercised but also unconscious ways. We make an effort to be open about our biases, privileges and commit to decostruct them and all hierarchies that we recognise. (see also the Feedback section below)

Listening

Consensus depends a lot on the circle deciding together, there is no debate and we do not try to be the loudest in the room or the one that argues for a longer time. Listening means focusing on the person that is talking instead of thinking how to respond to them.

We try to understand the other person’s perspective, feelings and experiences. Do not assume, instead ask questions to deepen your understanding or encourage a person to voice their views. All emotions and expressions are valid, and everybody has needs that they want to fill.

Remember that all of us have different backgrounds, experiences and privileges. We don’t all have the same platform, confidence or ways to express ourselves. We should be conscious every time somebody speaks (or doesn’t speak) of not only what the person is saying but also the context and the background the person has. The way somebody is saying something shows how important the issue is for them or what kind of background they have related to the discussion.

Questioning

Questions help us understand the perspective of everybody in the circle, but they need to be phrased with care to encourage participation in the circle. We try to avoid asking questions in a way that is:

accusatory - “You are the only one that disagrees, Why do you disagree?”, “Why are you trying to derail this proposal?”
asking for proof - “I understand that doing “this” makes you feel like “this” will happen, can you list some studies for that?“, “I have never felt how you feel. Do you know any people that do?”
interogating - asking a question one after another (usually with yes/no answer implied) to try to lead the person towards a specific decision
putting the person in the corner - “We all have a consensus here except for you. Can you tell us why you disagree?”

Questions can help us and others deepen our reasoning and self-reflect. We ask open-ended questions (where we do not expect a simple yes/no answer), ask clarifying questions on what we do not understand and offer summaries of what we heard asking if that is correct. We try to be honest and specific in our statements to avoid being misinterpreted.

Feedback

Feedback is the foundational value of everything we do at {Community name}. This has been mentioned in the Governance and in our Code of Conduct, here it will be mentioned in the context of making decisions and organizing work.

It is important to speak up when we see something done well or wrong as soon as we notice something so that the feedback is impactful and resentment doesn’t settle. Good feedback can help built trust and appreciation for our work, while critical feedback can build a safer culture that aims for self-reflection from its participants. We all participate and help build the culture we want to see in {Community name} by speaking our mind and being confident about what we believe. People affect each other, even if we do not intend to, and there is a variety of ways we can make things easier on others and help everybody fulfill their needs.

Before giving critical feedback try to collect your own thoughts and feelings and be clear with yourself what you want to achieve by giving that feedback. There are cases where that is not possible because either the situation is actively harmful or the person you are giving the feedback to - has developed a pattern. As it is said elsewhere all feelings are welcome and we will not tone-police people that try to speak up. If it is easier for another person or the mediation circle to speak on your behalf you are encouraged to do so.

Be conscious of the power balance that exists between the group and between you and the person you are giving or receiving the feedback from. Not all of us have the same privilege and we all have our preconceptions and prejudices that we come with into the group. In contrast with other communities we do not pretend we are neutral or “apolitical” but instead we openly acknowledge that each of us is affected by biases and has always more learning to do and more hierarchies of oppression to deconstruct. We make the effort to speak up when we see things happen and give platform to others to have equity.

When giving critical feedback try to:

make sure that the feedback is welcome at that moment, and the person is open to it. Not all times are the same and sometimes people are tired or out of spoons.
talk from a place that describes your own feelings and how you felt when the situation happened. Don’t try to assume what any participant meant/intended at the time or put blame on anybody instead leave the opportunity open for the person to explain. The purpose of this is to leave the opportunity for reconciliation open and to not get the other person into a state where they feel they have to defend themselves.
remember that every person comes into the circle with their own experiences and has their own needs. All beings deserve respect and our good faith before assuming things.
Consider the time and place. Not all feedback should be told privately or publicly, not all people deal with feedback the same way when it is given to them in public.

When receiving feedback try to:

not speak immediately in the form of justification, an emotionally-charged reaction, asking for proof, saying they have misunderstood, or you “don’t see it”. You can ask for details (with care as not to do what was listed), but don’t expect necessarily an answer. It is up to you to self-reflect, learn and talk with people that are willing to talk to you about this issue.
reply to the person giving the feedback after some time of self-reflection and delibaration (with others if needed and willing to talk about this). Make sure that the reply is actually wanted, helpful, and it doesn’t fall into one of the forms listed above, or it is being defensive.
not hold the person that gives the critical feedback accountable for your feelings. Its okay to feel upset, angry or sad, but it is not fair to expect the person giving you the critical feedback to support you through your feelings or for you to “tone-police” them.

The aim of feedback is not to come at a compromise, where everybody involved has to “sacrifice” some of their comfort to meet in “the middle”. The aim is to understand each others needs as well as experiences and decide together how to fulfill those needs.

While it is encouraged to give direct feedback, sometimes that is not always possible. Either because:

all communication has broken down
the action the other person is a violation of the Code of Conduct or causes direct harm
its hard to talk to people and give feedback

In these cases it is advised to contact the Mediation Circle to take steps to mediate the situation.

Summarising

A summary is putting in a few words what was said, to make sure that we understood what was said and that we are all on the same page. Summaries can help with making it clear what the topic we are currently discussing is, what objections/concerns we are trying to resolve, or make it easy to understand what position each person in the circle has. Summarising is also invaluable in making people feel heard and understood.

Some things to keep in mind while summarising are:

Summaries carry more weight than just phrasing an opinion, keep the possibility that a summary is wrong or misses something that was said open for other people to correct, to avoid shutting down discussion. This can be done by asking for validation from the circle and by presenting the summary as a subjective interpretation of what was said.
Pick you words carefully. Sometimes it is crucial to use the exact same words that were used (for example when phrasing a concern, feelings or a potential objection), other times it is better to use your own words to describe what was said (either to make it more easily understood or because it can be shorter as a summary).

Synthesis

Synthesis is the process of finding the “common ground” that was described in the plurality section. It combines all feedback into one proposal that works for everyone both inside and outside the circle.

This is done by respecting all people’s concerns and individual needs, as well as listening to community and the people that are directly affected by the proposal at hand. Not everybody’s voice is equal (either because of experience, privilege, impact or knowledge) and some people are more assertive than others, so the circle and the facilitator need to do the work to reflect that in the proposal.

Accountability

We all take decisions together as a circle. We all share responsibility in implementing our decisions, doing our tasks and the outcomes of both. It is important to be open when we need help or don’t have time and also when we are working on something or when we have finished something (the way to do these is up to each circle).

Groups thrive when there is:

open communication about what is currently being worked on, when people don’t have time/don’t have enough spoons or are stuck.
when there is appreciation, words of encouragements and a culture of being free to ask questions.
when each person is free to be their whole self with all their range of emotions and any events that happen outside of the circle (more on this in the Decision Making steps).
when each person is free to voice disagreements or improvements that they observe and when they can have a direct impact to change things.

On the other hand groups break down when:

decisions are taken and never implemented.
when its not clear who is doing what and tasks are stuck in “limbo” for years.
when communication is closed and people don’t feel free to pick up tasks, don’t feel like they can ask for help and feel guilty for not doing tasks even if they have valid reasos for taking their time (feelings, events outside of the circle, spoons, etc.).

To help make our circles thrive we commit to:

have a culture of appreciation, sharing good news and giving space to others to do their work at their own pace.
make all decisions that were taken understood/clear and all work that needs to be done and who is going to do it. (see summarising above).
encourage each person to bring their whole self and be a human being (not a cog in the capitalist machine). This means that people have feelings, sometimes they are tired or not up to do much (spoons or anything else), stuff happens in their lives and its okay to talk about it/support, and some people are neurodivergent (autistic or adhd or anything else) or are 2SLGBTQIA+ in some way. All people are encouraged to be themselves and we don’t keep our personal lives at the door.

Why not

Voting/Majoritarian Democracy

It needs a lot of infrastructure to make it work, private, secure and valid. Most organization develop their own service or use a third party service.
It easily becomes majoritarian/pushes minorities aside. Even with supermajority rules 20% - 25% of people are not heard.
You can’t have nuance in voting, all suggestions and concerns are pushed aside for a “simple” yes/no choice.

Unanimity/blocking-consensus

Decisions can be blocked by anybody which makes newcomers discouraged. It also promotes “drive-by” blocks where the person doesn’t know the topic but still blocks the proposal.
People need to do a disproportionate amount of work to actually block a proposal or suggest something else. (often by needing to create a whole separate proposal)
We “must agree” to like a proposal otherwise it does not pass.
the people that do things get to decide (see do-ocracy), without having to listen to the community

Show of hands

Show of hands is a variant of majoritarian democracy so all its drawbacks apply, but also it doesn’t have privacy so much higher social pressure to conform.

Special circumstances

Community-wide

By necessity the more people you have in your community the less equity your community has. Meaning, its very easy for 10-20 people to discuss and decide things that are okay with everybody, for 75-100 its harder. There comes a time where adding more and more people in a community (and “scaling it”) smooths over all the differences of people to make them homogenous and thus easier to organize things (like states do with languages and national “identities”). The decisions are more and more abstracted away because there are too many people and that creates a division between people that do the work and people who are no longer doing work everyday, therefore losing focus on the people actually doing the work.

That is not unique to consensus or sociocracy of course and voting will not help here. Voting systems fix this problem poorly, by making all decisions into a binary yes/no and erasing any concerns or nuance around decisions.

This is said not to discourage community-wide decisions or role selection, but to instead urge the reader to use the community-wide cases consciously and with intention and to be wary of “growth” and “scaling” of their community. Instead consider a diverse ecosystem with many small communities all collaborating with each other without needing to grow or scale (see also the Permacomputing document and Digital Commons).

Decisions

Some decisions affect the whole community (all circles and people that are in the community spaces), a good example of that being the Code of Conduct or deciding to move the space (offline or not) somewhere else. In these cases the circle model is not only innefictive but also exclusionary. For these cases the decision making variant described in the following section can be used.

Considerations

Deciding in large groups is hard and comes with its own set of challenges. Specifically:

Rounds can not be done and not everybody will get a chance to speak. It would take a disproportionate amount of time to do so and not be good for the participants. Instead the facilitator needs to find other ways to do a lot of the decision making steps asynchronously. Some examples include: post-it notes on the wall, a digital mind map or whiteboard, forms/questionnaires and comments in a forum.
Not all steps can be done together as a group. Synthesizing a proposal for example would result in problematic power dynamics and long meetings that people wouldn’t be able to pay attention to.
Because these decisions are taken by the wider community, with no membership and lesser access controls, there needs to be a way to filter the “noise” to reveal the opinions the community holds.

Decision making

[Exploration]

Exploration steps: Understanding the topic, Share considerations on the topic and Share ideas.

The exploration part of the decision making process can (and should) be done by the whole community synchronously or asynchronously in a any way the facilitator deems fit. The facilitator should leave adequate time for the community to read, ask questions, discuss and share ideas/perspectives on the topic. The timeline and the medium the exploration step will use is up to the facilitator.

It is infeasible to make sure that every single person in the community understood and contributed to the exploration step, both because there is no membership and because there may be too many people with different availability and desires. The goal of this step is for everybody that can and is interested in the proposal, to be given adequate time to deliberate and contribute. It is up to the facilitator to determine when that has been achieved and to make sure everybody is heard, otherwise take the necessary steps to achieve those goals.

[Synthesis] Proposal forming

Synthesizing the proposal can not be done with the whole community due to the reasons given in the considerations section. Instead a circle should take the responsibility to take all the feedback, ideas, considerations and concerns that were gathered and form a proposal (the circle that does this depends on the proposal at hand).

As noted in other sections in this document, the circle should try to integrate as many of the ideas as possible and it should make sure that it has all the feedback from the facilitator and the wider community. An effort should be made to balance people that may be affected by the decision more, may not have been heard as much or people that have less social privileges in the community. If the circle deems necessary to contact some person or group/community for additional input and feedback they are encouraged to do so.

[Feedback] Present the proposal, Clarifying Questions, Quick reactions round.

After the proposal has been synthesized the circle presents the proposal to the community. This can be done publishing the proposal in a public place (like a forum/chat or the entrance of the space), or presenting it in a community meeting. The community can ask questions and react to the proposal or give suggestions for improvement.

Depending on the feedback the circle receives it may alter the proposal and present it again (if there is too much negative feedback), or move the proposal to the next step and get everybody’s consent. Note that small corrections or changes that won’t change what the proposal is about should always be done in this step.

If the circle presents/publishes the proposal and there is a lot of negative feedback from the community, by either a large percentage or by people that are affected/less privileged in the community around the specific proposal, that is a message to the circle that it has failed to listen to the concerns and ideas of the community. Besides starting from scratch and crafting a new proposal, the circle should also do self-reflection on what wrong and what steps can be taken to fix it. The community has the right to know why the circle went wrong and what are the next steps being done to improve things in a transparent way.

Decision and implementation

When all the changes have been integrated to the proposal, the decision is taken with lazy consensus. If there are no serious concerns within a time frame given by the facilitator/circle then the proposal is considered to have consensus and it passes. The time frame should be long enough for people that have less time or less participation in the community.

Depending on what the proposal aims to do, the implementation can be done by the circle itself, the person that made the proposal, or the community-wide role selection process can be used further down this document. It may happen that the implementation part is not needed because the decision was taken for a new version of the Code of Conduct. It is up to each facilitator and/or circle to decide how the implementation should be done.

Quick decision making

Circle members sometimes have to make quick decisions without having the time to go through the decision making process described above.

If the situation is happening in a domain of an existing role, then the person that has the role can act on it, since they are already trusted by the circle to act autonomously in that specific area. There may be cases though when a person doesn’t have a role entrusting them to act. For these cases the circle should prepare proactively with guidance and agreements on what to do (these could be in the form of RFCs).

The agreements should specify (at a minimum):

a scale of urgency for each specific event (for example dangerous situations, sexual harrassement, police involved, time limit imposed by another entity (for funding or cooperation for example), etc)
what are the minimum number of members that need to be present at each scale of urgency
what are the limits of power the members have in each scale of urgency
how is a quick decision reversed or changed later if needed
how long should the sub-group wait for a reply before considering the person absent

The circle should keep track of who is available and when, so that it is clear who is available for a quick decision making session or not. This information should be available in the group in an easy to understand and up to date format so that quick decisions can be made timely without always waiting for responses.

In these time-constrained situations not the whole decision making process is followed. Instead the circle either immediately decides on a proposal (if somebody has already an idea for next steps) or synthesizes a proposal and decide what to do next. If time permits the circle can wait for people to respond that are not present or seek feedback on the proposal from people affected or other circles.

Making quick decisions like this requires a great amount of trust and familiarity with each other’s needs. The more circle members know each other (needs, reactions, beliefs, etc.) and the more they see each other as human beings, the easier and faster making quick decisions (and any other decisions) becomes. Building this kind of mutual understanding means that its clearer why each person talks the way they do, what do they mean between the lines and what are their hopes and fears. When the circle decides or forms a proposal people should anticipate each other needs and shift the proposal so that it fits everyones needs, including potentially people that are not present in the meeting.

Note that if urgent decisions are coming up often in the group, then consider that maybe a role needs to be created to empower a person to make decisions or decide on a guideline (can be an RFC) on how to handle specific cases without a group meeting every time.

Templates

RFC Template

Problem Statement

Describe the problem that the RFC aims to solve and why the problem exists.

Proposal

The proposal to solve the above problem.

Alternative Proposals

List alternative Proposals or ideas that were considered and why they were rejected.

Who it affects

List people and groups that this proposal affects/may affect.

Rationale

What is the impact of not doing this?

Impact

What could go wrong when we do this? What should we be careful for?

How will the proposed change evolve with time? What is the cost of changing the approach later?

How do we know we succeeded

What are the visible/measurable improvements this proposal is going to make if it’s implemented?

Previous Versions

Everytime the RFC changes version write a note on what changed here. One entry per version.

Comments from previous review sessions.

Any comments or concerns from the previous review sessions.

Mediation Circle

This folder includes all documents that are managed by the Mediation Circle in your community (or any other group that handles reports and manages these documents).

Code of Conduct

To use the Code of Conduct in your space, 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 culture.
Change the “See our Governance for more information.” with a link to your own Governance document. If that doesn’t exist feel free to remove it.

The Code of Conduct may be updated again in the future, please make sure you remember the version you copied.

References

The following Code of Conducts are given as source for reading or to add more things to the CoC.

Mediation Process

To use the Mediation Process in your space, 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 culture.

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

References

The following Mediation Processes are given as a source for reading or inspiration for your own Mediation Process.

https://conduct.gnome.org/reporter-guide/
https://lgbtq.technology/coc.html

Code of Conduct

{Community name} is a community dedicated to {write the goal of your community here}. It promotes cultural diversity and international cooperation; we want to empower people to communicate without any form of oppression or barriers. See our Governance for more information.

We acknowledge that we come from different backgrounds and all have certain biases and privileges. Therefore, this Code of Conduct cannot account for all the ways that people might feel excluded, unsafe or uncomfortable. We commit to open dialogues, and as such this Code of Conduct is never finished and should change whenever needed. It is a collective responsibility for all of us to enact the behaviour described in this document, and bring it to the physical and digital space of {Community name}.

This code of conduct applies to all our spaces, both online and off. Please report to the Mediation Circle any problematic behavior you see regarding people in our spaces or members of the {Community name}. This includes behavior outside of {Community name} spaces at any point in time.

This list is not exhaustive and the mediation team may decide to take actions disregarding the list if necessary. A member of the community not doing anything explicitly against the Code of Conduct may also be requested to leave if they take too much time and energy away from the mediation team.

Culture Guidelines

We follow the Permacomputing Principles and the Social Rules of the Recurse collective.
Consent: No unsolicited advice, respecting the autonomy of people using our server/app, respecting the privacy and boundaries of other people in the network.
Plurality of views, experiences and backgrounds to foster an inclusive environment. We recognize that not everyone has the same opportunities, therefore we must be sensitive to the context we operate in and see implicit hierarchies that we can challenge. We think about how we can consider degrees of privilege, account for the needs of others, promote an activist stance and support/give platform to other voices. We expect people to be willing to examine their privilege, language and other habits while they are here, and work on a growing understanding of intersectional feminism.
A spirit of collaboration and consensus for working on projects instead of meritocracy. We focus on what is best not just for us as individuals, but for the overall community because tech people are not inherently smarter than others or care more for certain things. We try to respect the dignity, experiences, and perspectives of those that are implicated by the work we do even if they are not here and give them respect and consideration.
Being open for self-reflection both in ourselves and our communities/people/figures/organizations. We speak up when we see them do wrong, reform them and remove the people that did/enable it. If we fail we create new ones and denounce these that don’t want to change.

We as a community pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal or physical appearance, race, caste, color, religion or lack thereof, neuro(a)typicality, sexual identity and orientation, immigration status, language, or other identity marker. If you’re unsure if a word is derogatory, don’t use it. This also includes repeated subtle and/or indirect discrimination.

In {Community name} we consider impact before intent and we prioritize marginalized people’s safety over privileged people’s comfort. The mediation team reserves the right not to act on complaints regarding:

“Reverse” -isms, including “reverse racism”, “reverse sexism”, and “cisphobia”.
Reasonable communication of boundaries, such as “leave me alone”, “go away”, or “I’m not discussing this with you”.
Communicating in a “tone” you don’t find congenial. The expression of justified anger will not to be policed within this space. Tone policing and the expectation of politeness have long been used as tools for oppression, as reasons for dismissal of valid arguments, and we will not be complicit in propagating that behaviour.
Criticizing racist, sexist, cissexist, terf (trans-exclusionary radical feminism), white feminism or otherwise oppressive/hierachical behavior or assumptions.

Basic expectations for conduct are not covered by the “reverse-ism” clause and would be enforced irrespective of the demographics of those involved. For example, racial discrimination will not be tolerated, irrespective of the race of those involved. Nor would unwanted sexual attention be tolerated, whatever someone’s gender or sexual orientation. Members of our community have the right to expect that participants in the project will uphold these standards.

Acceptable behavior within our spaces:

Asking before assuming, no question is too obvious or should be known before asked. For example what someone’s preferred pronoun is, whether they know anything about a subject. If we are unsure, we ask for clarity. We also understand that not all questions are OK, or need answering.
Be empathetic, by actively listening to others and not dominating discussions. We give each other the chance to improve and let each other step up into positions of responsibility. We are aware of each other’s feelings, abilities and provide support while knowing when to step back. We ask to make sure that our actions are wanted. Leaving physical, emotional and conceptual room for other people.
Giving and gracefully accepting constructive feedback. Accepting responsibility, apologizing to those affected by our mistakes, and learning from the experience.
Caring for our physical and digital environment. We respect and pay attention to the beings (human or not), facilities, infrastructures and objects brought together and treat them with the necessary care.

Unacceptable behavior within our spaces:

Harassment, such as outing of any aspect of a person’s identity or their information (including messages) without their consent and continued one-on-one communication after requests to cease.
Stalking including virtual following (locating someone in other web spaces in order to continue unwelcome contact) and logging/recording online conversations for harrassement purposes.
Debating the rights and lived experiences of marginalized people. Questioning or challenging someone’s stated self-identity or chosen labels, even if they conflict with your own views. This includes misgendering or use of “dead” or rejected names.
The use of sexualized language or imagery, and sexual attention or advances of any kind. This includes simulated physical contact (such as emojis like “kiss”) without affirmative consent or after a request to stop.
Child Sexual Abuse Material (CSAM), in all its manifestations (including animations or illustrations).
Hate speech, hierarchical ideas/behaviors and religions. This includes (among others) in all their forms and manifestations: fascism, white supremacy, colonialism, imperialism, nationalism (especially ethno-states), capitalism, racism, sexism, ableism, transphobia, queerphobia and militarism.
Misinformation, disinformation and propaganda (especially state propaganda) that seek to promote pseudoscience, conspiracies or deny/cast doubt in historic and ongoing acts of genocide.
Violence, incitement or threats of violence (both physical and psychological) towards another participant, community or group, including encouraging someone to engage in self-harm.

Code of Conduct Quick Reference

Important Contacts

name = “”, pronouns = “/” / {add details here} name = “”, pronouns = “/” / {add details here}

Behavior Guide

Behavior	Should Be
Damaging Intentions	Identified and discouraged. Speak up!
Honest Mistakes	No ones perfect. Pay attention to constructive feedback.
Move Fast & Break	Asking for consent and respecting when consent is denied.
Feels Wrong	Don’t do it. Take a break, clear your head. Do self care.
’Stupid Questions’	Impossible. No question is invalid, or too obvious.
‘Freedom of ______’	We define kindness within our community environment.
Creepy Vibes…	Unacceptable. Words and flirts CAN hurt. End coercion.
Users vs Developers	Everyone involved, anywhere. Skill DIVERSITY, not division.

Constructive Criticism Guide:

Ask consent first. Don’t forget to wait for the answer!
Paraphrase, repeat, or describe the work to empathize with the other person.
Discuss what’s working, what is helpful, and what you want more of.
Talk candidly about shortcomings. Be polite. Plant seeds for growth.
Theres rarely only one good way to do something, and everything has a drawback.

Conflict Resolution Guide:

Collect thoughts and emotions before the impulse to act rashly.
Be authentic. This process is always awkward. That’s okay.
Set boundaries clearly. You are encouraged to enforce them.
Use “I” instead of “You. Set aside expectations or assumptions of others.
Express feelings and release them without dwelling. Let it be cathartic, and then over.
Patience. Everyone feels ready to leave something behind at their own speed.

Remember: Designs mirror creator relationships. Treat others with the service you want to build.

Mediation Process

The mediation circle is responsible for upholding the Code Of Conduct. It accepts reports for violations and acts on them. The current Mediation Circle members are {Link to your mediation circle document}.

In order to protect volunteers from abuse and burnout, we reserve the right to reject any report we believe to have been made in bad faith. Reports intended to silence legitimate criticism may be deleted without response.

How to make reports

In case of harassment, abusive behavior, or if there’s something else making you feel uncomfortable/unsafe/excluded, or have any other concerns, please contact a member of the mediation team that you are comfortable with.

Please note that people that manage the server have administrative access to the server. The members are listed {link to the section in your mediation circle document that lists server admins}. If a report is received that involves an sysadmin, all mediation team discussion and documentation will occur off the servers the room is hosted on. Sysadmins making a report and people reporting Sysadmins are encouraged to contact mediation members individually via private means.

If someone from the mediation/moderation teams is involved in a conflict, they would restrain themselves from participating in mediation activities regarding this conflict. The incident documentation will not be available to them, and they will excuse themselves from any conversations involving handling the incident.

Activities of the mediation team happens in a channel accessible only to its members. If necessary and with the consent of the person doing the report, an invitation can be sent to include other members than the mediation team.

What to include in reports

Some general information that will helps us act on the report is listed below. If you don’t remember all the details, we still encourage you to make a report.

Your contact info (so we can get in touch with you if we need to follow up).

If you prefer to be anonymous, mention it to the mediation team member you are reporting to. They will not mention any names or any other contact information. This means you won’t get any updates/followups later about the report.

Date and time of the incident
Whether the incident is ongoing
Which online community and which part of the online community space it occurred in
Description of the incident
Identifying information of the reported person such as name, online username, handle, email address, xmpp address, or anything else
A link to the conversation
Any logs or screenshots of the conversation
Additional circumstances surrounding the incident
Other people involved in or witnesses to the incident and their contact information or description

Mediation team Processes

If the incident is ongoing and needs to be immediately addressed, any member of the mediation team may take any action deem necessary for the safety of the person making the report and the safety of the community at their discretion.

A follow up will be sent to the person as soon as the mediation team meets that may include:

An acknowledgment that the mediation team discussed the situation
Whether or not the report was determined to be a violation of the Code of Conduct
What short-term actions is the mediation team taking to make the person that did the report feel safe.

We will respect confidentiality requests for the purpose of protecting victims of abuse. At our discretion, we may publicly name a person about whom we’ve received harassment complaints, or privately warn third parties about them, if we believe that doing so will increase the safety of the members or the general public. We will not name harassment victims without their affirmative consent.

Some incidents happen in one-on-one interactions, and even if the details are anonymized, the reported person may be able to guess who made the report. If you have concerns about retaliation or your personal safety, please note those in your report. We still encourage you to report, so that we can support you while keeping our community members safe. In some cases, we can compile several anonymized reports into a pattern of behavior, and take action on that pattern.

Resolution

When we receive a report we will contact the person(s) involved to have a conversation with them. We may revoke access to workshops, activities and physical or digital collaboration spaces if an individual’s unacceptable behavior persists. We also may identify the participant as a harasser to other members or the general public.

A person from the mediation team will also follow up with the person that made the report to let them know:

What action(s) were taken in response to the report.
If applicable what changes were made so that this does not happen again.

Reading material for mediation circle members and moderators

https://conduct.gnome.org/committee-procedures/
https://geekfeminism.fandom.com/wiki/Conference_anti-harassment/Policy
https://geekfeminism.fandom.com/wiki/Conference_anti-harassment/Responding_to_reports
https://policies.python.org/us.pycon.org/code-of-conduct/Enforcement-Procedures/

Keyboard shortcuts

Vojkruco