- Layer: 5 — Operations & Coordination
- Status: Template — adapt for your community
- RCOS reference: §7.1, §7.3, §7.4, §7.5, §7.6
Core Operational Processes
RCOS clauses: 7.3.4, 7.7.2, 7.6.3
Why document critical processes?
If a process only lives in one person’s head, the community depends on that person showing up — forever. Writing the critical processes down, with named owners, is what converts private knowledge into a community asset that survives handovers, absences, and exits.
How to fill this in
For every recurring critical process (onboarding, exit, proposal publication, contribution recording, meeting cadence, treasury management, platform access review), name an owner and a brief description.
| Process | Who | Detail |
|---|---|---|
Temporary and Ad-Hoc Responsibilities
RCOS clauses: 7.1.5, 7.1.4, 7.7.1
Why cap temporary responsibilities?
Ad-hoc tasks quietly calcify into permanent unpaid jobs — usually on whoever said yes once. A hard time-box and a forced review make the difference between “I covered for a week” and “apparently this is my role now.”
How to fill this in
State that any temporary responsibility must be time-bounded at assignment, documented, reviewed before expiry, and either formalised or terminated.
When a task or responsibility is assigned temporarily, it must be:
Role and Domain Interfaces
Why map handoffs explicitly?
Most operational failures happen not inside a role but between roles — at the boundaries where work moves from one owner to the next. Naming the handoffs turns invisible dependencies into reviewable ones, and prevents “I thought you had it” failures.
How to fill this in
For each pair of roles that pass work to each other, name the handoff and the type of work transferred.
| From | To | Handoff |
|---|---|---|
| <…> |
Workload Boundaries
RCOS clauses: 7.4.1, 7.4.2, 7.4.3, 7.7.3
Why make workload limits explicit?
Unbounded coordination load is the default failure mode of volunteer communities — it quietly burns out the most committed members until they leave. Explicit, reviewable limits make capacity a shared concern rather than a private burden.
How to fill this in
Set bounds on meeting load, role load, response-time expectations, and the path for renegotiating responsibilities.
- Meeting load:
- Role load:
- Response time expectations:
- Renegotiation and relief:
Operational Continuity
RCOS clauses: 7.5.1, 7.5.2, 7.5.3
Why plan for continuity now?
A community that depends on one irreplaceable person is one illness, one conflict, or one exit away from collapse. Naming the single points of failure — honestly — and building handover into every role is what keeps the community surviving its founders.
How to fill this in
Name current single points of failure honestly. State the handover requirement for each role and the cadence of continuity review.
- Current state:
- Handover mechanisms:
- Continuity review cadence:
Information Flow and Anti-Gatekeeping
RCOS clauses: 7.3.5, 7.7.4, 7.3.2
Why treat information access as a governance issue?
Whoever controls access to information controls the community, whether they mean to or not. Making access rules explicit — and disallowing sole points of access — is what prevents informal gatekeepers from accumulating the kind of power the governance system is supposed to check.
How to fill this in
State which records are open to all Full Members, the response window for information requests, and the rule against sole points of access for governance-relevant information.
Documentation Locations and Update Procedures
RCOS clauses: 7.3.1, 7.3.2, 7.3.3
Why name where every document lives?
If no one can say where the canonical version of something lives, there is no canonical version. Naming the location, owner, and review cadence for each document type is what makes the community’s memory auditable rather than folkloric.
How to fill this in
For each document type, name the canonical location, the owner, and the review cadence.
| Document type | Location | Owner | Review cadence |
|---|---|---|---|
Ratification Record
- Adopted:
- Decision type: Strategic
- Version:
- Decision record: