- Layer: 5 — Operations & Coordination
- Status: Template — adapt for your community
- RCOS reference: §7.1, §7.6
Overview
RCOS clauses: 7.1.1, 7.1.2, 7.1.4, 7.7.1
Why require every responsibility to have a named role?
Ongoing responsibilities without explicit roles become invisible labor — done by whoever notices, resented silently, and impossible to hand over. Making every ongoing responsibility a named, accountable role is what prevents the community from running on the unpaid goodwill of a few members.
How to fill this in
Distinguish operational roles (carrying delegated authority per the Decision Matrix) from functional roles (contribution-scoped, no special governance authority). State the “in good standing” definition you will use for eligibility.
This registry defines all recognized roles within the community. Roles are either operational (carrying delegated authority per the Decision Matrix) or functional (contribution-scoped, no special governance authority beyond Full Member rights).
“In good standing” means a Full Member who has met their participation expectations in the last
and is not currently subject to an active accountability process or conflict review under Layer 4.
Summary Table
| Role | Type | Current Holder |
|---|---|---|
| <…> | <…> | <…> |
Operational Roles
Why define accountability for delegated authority?
Operational roles carry real power — they can act without a community vote within their scope. That power only stays safe if each role has a clear accountability mechanism: who can raise concerns, how review happens, and how a role can be reassigned when trust breaks.
How to fill this in
For each operational role, fill in the template below with concrete scope, decision authority, interfaces, eligibility, term, appointment, review/removal, and handover requirements.
Operational roles carry delegated authority to act within explicitly defined limits without a Full Member vote, as defined in the Decision Matrix (Layer 2). All operational role holders are accountable to Full Members collectively. Any Full Member may raise a concern about how a role is being performed; reassignment requires a Strategic vote.
- Purpose:
- Scope of responsibility:
- Decision authority:
- Interfaces:
- Eligibility criteria:
- Term / rotation:
- Appointment process:
- Review and removal:
- Handover:
- Purpose:
- Scope of responsibility:
- Decision authority:
- Interfaces:
- Eligibility criteria:
- Term / rotation: <…>
- Appointment process: <…>
- Review and removal: <…>
- Handover: <…>
Functional Roles
Why separate functional from operational roles?
Not every contribution needs delegated authority — most work is about doing, not deciding. Functional roles name contribution scopes without bundling in governance power, so members can opt into work without an authority transfer, and so the governance system stays clear about who can act on behalf of the community.
How to fill this in
For each functional role, define purpose, scope, interfaces, eligibility, and handover. Functional roles do not require a vote to assume — declaration is sufficient.
Functional roles define a member’s contribution scope. They carry no delegated governance authority beyond Full Member rights. Any Full Member may take on a functional role by declaring it; no vote is required. Roles may be vacated at any time by notification.
- Purpose:
- Scope of responsibility:
- Decision authority:
- Interfaces:
- Eligibility criteria:
- Term / rotation:
- Appointment process:
- Review and removal:
- Handover:
Ratification Record
- Adopted:
- Decision type: Strategic
- Version:
- Decision record: