Change Protocol
Download this template
Generated 2026-08-31 · Download all templates
How Changes Are Proposed
How does somebody propose adding, changing, pausing or removing one of our rules, roles or structures?
RCOS clauses 8.1.1, 8.1.3, 8.6.3, 8.8.1
Why require a structured proposal?
A change that arrives as a vague idea in chat cannot be evaluated, challenged, or rolled back later. Forcing every proposal through the same minimum shape — affected artifacts, rationale, risks, rollback — turns an opinion into a reviewable artifact and makes it impossible to slip a rule change past the community by accident.
How to fill this in
State who may propose, where proposals are submitted, and the mandatory content fields. Tie this to the Governance Protocol (Layer 2).
<Any Full Member may propose a change to any RCOS artifact. State the submission channel.> Every proposal must include:
- <Summary of the change.>
- <Affected layers and artifacts (with links).>
- <Decision type (Operational / Strategic / Constitutional).>
- <Rationale.>
- <Risks and mitigations.>
- <Rollback plan.>
- <Proposed effective date.>
What to cover
- Who may propose adding, changing, pausing or removing a rule, role, document or way of deciding?
- Where is a proposal submitted, and who makes sure it reaches everyone?
- Which documents and sections does the proposal have to name as affected?
- Which decision type and which decision path from our Decision Matrix does the proposal have to name — and so who decides it?
- What must every proposal say about its purpose, its reach and its known risks?
- What must it say about its effective date, any transition period, what happens to existing roles, agreements and records, and how it would be undone? (How long it is reviewed, and what happens in an emergency, are their own questions.)
Examples
Any Full Member may propose adding, changing, pausing or removing a rule, role, document or decision structure by filling in the proposal form in the proposals folder and telling the facilitator. The form names the documents and sections affected, the decision type and path from our Decision Matrix, what the change is meant to do, how far it reaches and its risks, the effective date and any transition period, what happens to existing roles, agreements and records, and how it would be rolled back. Incomplete forms are returned before discussion starts.
Examples, not recommendations. Your answers will be your own.
How Proposals Are Classified
How do we tell a small adjustment from a change to who we are — and a permanent change from an experiment?
RCOS clauses 8.1.2, 8.1.4
Why classify by impact?
Not every change deserves the same friction. Typo fixes should not need a supermajority; constitutional shifts should not pass quietly. Mapping proposals to decision types — and defaulting unclear cases upward — makes the cost of a change proportional to its blast radius and protects Layer 0 from being eroded through small moves.
How to fill this in
Define what falls under each decision type. State the default-higher rule for ambiguous cases.
- Operational: <wording corrections, formatting, minor content updates; no vote required; executed by the responsible role within delegated limits.>
- Strategic: <changes to Layer 1–5 content that affect member rights, processes, or structures.>
- Constitutional: <changes to Layer 0 (purpose, scope, invariants) or to the governance system itself (Layer 2).>
> If classification is unclear, it defaults to the higher-impact type.
What to cover
- For each decision type (for example Operational, Strategic, Constitutional): what kinds of change fall under it?
- Which changes are always Constitutional — such as anything touching our purpose, our scope, the commitments we said would never change, or how we govern ourselves?
- How do we tell a permanent change from a time-limited experiment, and where is that written on the proposal?
- When it is unclear which type a proposal is, which type applies, and who settles a disagreement about it?
Examples
Wording fixes and formatting are Operational: the document keeper makes them and lists them at the next circle. Changes to how members join, decide, share costs or hold roles are Strategic. Anything touching our purpose, our scope, our non-negotiable commitments or the way we govern ourselves is Constitutional and goes through the Constitutional decision process. A proposal with a fixed end date is filed as an experiment; everything else is permanent. If we disagree about the type, the higher one applies.
Examples, not recommendations. Your answers will be your own.
Review and Deliberation
How long does a proposed change have to sit before we are allowed to adopt it?
RCOS clauses 8.1.2, 8.7.1
Why enforce minimum deliberation windows?
Without a floor on deliberation time, any change can be rushed through on a slow day when few members are paying attention. Mandatory minimums — longer for higher-impact changes — guarantee that members who are travelling, ill, or simply busy still get a real chance to read, object, or show up.
How to fill this in
Set minimum deliberation periods for each decision type, and a ratification period for Constitutional changes.
- Operational: <no deliberation required.>
- Strategic: <minimum X-day deliberation; deliberation venue.>
- Constitutional: <minimum Y-day deliberation; Z-day ratification period after the vote passes.>
What to cover
- For each decision type: what is the shortest time a proposal must be open for discussion before it can be decided?
- Where does the discussion happen, so that members who are away, ill or busy can still read and respond?
- For Constitutional changes, how long is the ratification period after the vote passes, and what can members do during it?
- If some small changes need no waiting period, how can members still see them and ask for a proper review afterwards? (Urgent changes are their own question.)
Examples
Operational changes need no waiting period but are posted in the changes channel for 7 days, during which any member can ask for a full review. Strategic proposals stay open for at least 14 days, including one general meeting, before a decision. Constitutional proposals need at least 30 days of discussion and, after the vote passes, a 14-day ratification period in which any Full Member may call for a second vote.
Examples, not recommendations. Your answers will be your own.
Adoption and Publication
When a change is adopted, how does everyone find out, and from when does it apply?
RCOS clauses 8.2.1, 8.2.2, 8.2.5, 8.6.3
Why fixed publication steps?
A vote that passes but is never written down is the same as no vote at all — and worse, it creates a gap where whoever remembers the outcome gets to define it. Tight, ordered publication steps close that gap and make "what was adopted" a matter of record, not of memory.
How to fill this in
State the ordered steps that must run after a proposal passes. Include time bounds and the version-history obligation.
When a proposal passes:
- <Proposal file moved to the passed-proposals archive within X days.>
- <Affected artifacts updated within X days.>
- <Version history entry added.>
- <Status fields updated on affected artifacts.>
What to cover
- Once a proposal passes, which steps follow, in what order, and within how many days?
- Who is responsible for updating the affected documents and adding the Version History entry? (What the entry contains is its own question.)
- How are all members told about the change, and what does the notice include?
- From when does an adopted change apply — and can it ever apply before it is published?
- What happens if a change was agreed but never written up — does it count?
Examples
Within 7 days of a change passing, the secretary updates every affected document, marks the old wording as superseded, adds a Version History entry and moves the proposal to the passed-proposals folder. All members then receive an email with a summary and the effective date. The change applies from the effective date named in the proposal, or from publication if that is later. A change that has not been written up this way is not in force, however clearly people remember agreeing to it.
Examples, not recommendations. Your answers will be your own.
Rejection
What happens to a rejected proposal — can it come back, and how soon?
RCOS clauses 8.2.2, 8.2.4
Why archive rejected proposals?
Rejected ideas carry as much signal as accepted ones — they show what the community considered and declined. Keeping rejections filed and accessible prevents the same proposal from reappearing under a new name every six months and gives future members a view of the paths not taken.
How to fill this in
State the archive location for rejected proposals and the re-vote conditions for revisiting the question.
When a proposal is rejected:
- <Proposal file moved to the rejected-proposals archive within X days.>
- <No artifact changes made.>
- <Re-vote mechanism applies if new information emerges (per the Decision Matrix, Layer 2).>
What to cover
- Where is a rejected proposal kept, together with its decision record, and within how many days is it filed?
- Is the proposer told why it was rejected, and by whom?
- Can the same proposal come back — after how long, or only with new information?
- Who decides whether a returning proposal is really new, or the same one under a different name?
Examples
Within 7 days, a rejected proposal is filed in the rejected-proposals folder with its decision record and a short note of the main reasons given. Nothing in our documents changes. The same proposal may come back after six months, or sooner if the proposer shows new information that was not available during the first discussion; the facilitator decides whether a returning proposal is substantially the same.
Examples, not recommendations. Your answers will be your own.
Transition and Migration
What extra care does a change that is hard to undo need — and what happens to what is already running under the old rule?
RCOS clauses 8.5.1, 8.5.2
Why protect existing rights during transitions?
If new rules could silently rewrite existing agreements, membership would be meaningless — what you signed up for could be changed out from under you. Explicit transition rules guarantee that rights are not reduced retroactively and that people operating under the old rules are given time and notice before the ground shifts.
How to fill this in
State the rules protecting existing role holders, members, and records when a rule change takes effect.
When a rule change affects existing roles, agreements, or records:
- <Existing role holders notified before the change takes effect.>
- <Existing members' rights may not be reduced without consent or a Constitutional vote.>
- <Records that predate the change are not retroactively altered unless explicitly part of the proposal.>
- <A transition period may be defined in the proposal itself.>
What to cover
- How do we recognise a change as high-impact or hard to undo, and who decides that it is?
- For those changes, how much longer is the discussion, and what higher threshold do they need?
- How are the risks written down and acknowledged before the decision?
- How much notice do current role holders and members get before a change affects them?
- Can a change reduce the rights existing members already have, and if so, what does it take?
- What happens to records and agreements made under the old rule — are they left as they were?
Examples
A change counts as high-impact if it affects money, housing or membership rights, or cannot easily be undone. Such changes get twice the normal discussion time, need a two-thirds majority instead of a simple one, and include a written risk section that members acknowledge before voting. Affected role holders are told at least 30 days before the change takes effect. Existing members' rights are never reduced without their consent or a Constitutional vote, and records made under the old rule are not altered.
Examples, not recommendations. Your answers will be your own.
Rollback
How do we check whether a change is working — and revise or undo it if it is not?
RCOS clauses 8.1.5, 8.5.1
Why make rollback symmetrical with adoption?
A change that cannot be undone through the same path that created it is a trap. Requiring rollback to use the original decision type keeps the door open for correction without letting a single member quietly reverse a community-level decision by calling it a "fix."
How to fill this in
State that rollback uses the same decision type and process as the original adoption.
<Any passed decision can be reversed through the same process as the original. Any Full Member may trigger a re-vote by submitting a written reasoned objection that was not considered during the original deliberation. Rollback uses the same decision type as the original.>
What to cover
- How and when do we check whether an adopted change is working as intended?
- What signs mean a change needs revising or reversing — such as harm, instability, or decisions gathering in fewer hands?
- Who may ask for a change to be revised or reversed, and what do they have to show?
- Which decision type and process does a reversal use?
- When choosing between ways to solve a problem, how do we favour the one that is easier to undo?
Examples
Every adopted Strategic or Constitutional change is reviewed six months after it takes effect: the stewardship circle reports whether it caused harm, confusion, or put decisions into fewer hands. Any Full Member can ask for a change to be revised or reversed by giving written reasons that were not considered the first time. A reversal uses the same decision type as the original adoption. When two options would solve the same problem, we choose the one that is easier to undo.
Examples, not recommendations. Your answers will be your own.
Emergency Changes
What may we decide in a hurry, who may do it, and when does it expire?
RCOS clauses 8.5.3
- 8.5.3 Emergency changes MAY be permitted only where explicitly defined, MUST be time-bounded, MUST NOT override Layer 0 invariants, and MUST undergo mandatory post-hoc review and ratification or rollback.
Why allow emergency changes at all?
Some harms unfold faster than a vote can be convened. A narrow, well-guarded emergency path lets the community respond to genuine safety or platform failures without handing anyone a general-purpose override. The mandatory report, review, and ratification-or-rollback cycle is what keeps emergency powers from becoming ordinary powers.
How to fill this in
Define the conditions under which an emergency change may be made, who can make it, and the mandatory report-review-ratify-or-rollback cycle.
An emergency operational change may be made by <role> only if all of the following conditions are met:
- <Immediate action required to prevent safety harm or platform failure.>
- <A Full Member vote cannot be convened in time.>
- <The change does not override a Layer 0 invariant.>
Emergency changes must be:
- <Reported to all Full Members within X hours.>
- <Reviewed at the next community meeting.>
- <Ratified via the appropriate decision type within Y days, or automatically rolled back.>
What to cover
- What situations count as an emergency — and what makes waiting for a normal decision impossible?
- Who may make an emergency change, alone or together with someone else?
- What can never be changed in an emergency, such as our purpose or the commitments we said would never change?
- How quickly must an emergency change be reported, and to whom?
- When is it reviewed, and by when must it be confirmed through the normal decision type — or does it end automatically?
Examples
The two safety coordinators together may make an emergency change only when immediate action is needed to prevent harm to people or loss of the building, and a members' meeting cannot be held in time. An emergency change can never alter our purpose or core commitments. It is reported to all members within 24 hours, discussed at the next meeting, and lapses after 21 days unless members ratify it through the decision type the change would normally need.
Examples, not recommendations. Your answers will be your own.
Experiments
How do we try something for a while without it quietly becoming permanent?
RCOS clauses 8.3.1, 8.3.2, 8.3.3, 8.3.4, 8.3.5, 8.7.3
- 8.3.1 The community MAY adopt experiments as explicitly time-bounded and reversible deviations, extensions, or pilots intended for learning.
- 8.3.2 Every experiment MUST define, at minimum:
- 8.3.3 Experiments MUST NOT override Layer 0 invariants and MUST NOT bypass governance constraints defined in Layer 2.
- 8.3.4 Experiments MUST be explicitly labeled as experimental in all affected artifacts and MUST include a non-extendable expiration date unless renewed through an authorized decision.
- 8.3.5 If an experiment introduces safety risk, coercion, or sustained harm, the community MUST suspend or terminate the experiment immediately through a protective action, followed by post-hoc review.
- 8.7.3 Experiments MUST be time-bounded, explicitly labeled, and reversible.
Why treat experiments as a distinct mechanism?
The community needs a way to try new things without having to permanently adopt them to test them. Experiments create that space — but only if they are time-bounded, labeled, and auto-expiring. Without those guardrails, an "experiment" becomes the fastest way to install a permanent rule with no real deliberation.
How to fill this in
Define the rules every experiment must satisfy. Reference the Experiment Template for the full submission shape.
<Any Full Member may propose a time-bounded experiment via Strategic decision. See the Experiment Template for the required fields.>
- <Experiments expire automatically at the end of their defined duration unless explicitly renewed via a new proposal.>
- <All artifacts affected by an experiment must be explicitly labeled as experimental for the duration.>
- <Safety suspension: if an experiment introduces a credible safety risk, coercion, or sustained harm, an emergency suspension may be invoked per Emergency Changes above.>
- <Results and learnings are recorded in the Learning Log.>
What to cover
- Who may propose an experiment, and which decision starts, extends, changes or ends one?
- What must every experiment state — what changes and what stays the same, how long it runs, its check-in points, and the signs of success or failure?
- What triggers a rollback, and how is it carried out?
- What may an experiment never touch, such as our core commitments or the way decisions are made?
- How is an experiment labelled in every document it affects, and what fixed end date does it carry?
- If an experiment causes harm, pressure on people or a safety risk, who may stop it at once, and how is that reviewed afterwards?
Examples
Any Full Member may propose an experiment of up to 12 months; starting, extending or changing one takes a Strategic decision. The proposal states what changes and what does not, a midpoint check-in, signs of success and failure, and how to roll back. Every affected document is labelled "Experimental until" its end date. Experiments cannot change our core commitments or skip our decision rules, and they end on their date unless renewed by a new decision. Any two stewards may halt one immediately if it causes harm, with a review within 14 days.
Examples, not recommendations. Your answers will be your own.
Ratification Record
- Adopted: <YYYY-MM-DD>
- Decision type: Constitutional
- Version: <version>
- Decision record: <link to decision record>