Role Registry
Download this template
Generated 2026-08-31 · Download all templates
Overview
Which ongoing jobs have a name and a person, rather than being everybody's and nobody's?
RCOS clauses 7.1.1, 7.1.2, 7.1.4, 7.7.1
- 7.1.1 All ongoing responsibilities MUST be assigned to explicit, named roles rather than implicit expectations or informal agreements.
- 7.1.2 The community MUST maintain a Role Registry that includes, at minimum:
- 7.1.4 No ongoing responsibility MAY exist without an explicit role, and no person MAY be held accountable for responsibilities not formally assigned to a role.
- 7.7.1 Ongoing responsibilities MUST NOT exist without an explicit role.
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 <period> and is not currently subject to an active accountability process or conflict review under Layer 4.
What to cover
- Which ongoing responsibilities do we have today, and does each belong to a named role — or is some of it still done by whoever happens to notice?
- What makes a role operational (it may act for the community within set limits) rather than functional (it does work but carries no special say)?
- What does ‘in good standing’ mean for anyone who wants to take on a role?
- What must every role entry contain — purpose, scope and authority, boundaries with other roles, who is eligible, term, and how holders are appointed, reviewed and removed?
- How do we make sure nobody is held responsible for work that was never assigned to their role?
- How often do we check the registry against the work actually being done, and who does it?
Examples
Every ongoing task belongs to a role in this registry; if it is not listed, nobody can be held to it, and whoever notices proposes a role for it. Operational roles may act for the community within limits set in the Decision Matrix; functional roles do work but carry no extra say. A member is in good standing if they are up to date on agreed contributions and not suspended. Each entry lists purpose, scope and authority, boundaries, eligibility, term, and appointment, review and removal. Stewards check the registry every six months.
Examples, not recommendations. Your answers will be your own.
Summary Table
| Role | Type | Current Holder |
|---|---|---|
| <Role name> | <Operational / Functional> | <holder or "Vacant"> |
| <...> | <...> | <...> |
Operational Roles
For each role that keeps things running, what is it answerable for and who reviews that?
RCOS clauses 7.1.2, 7.1.3
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.
<Operational Role Name, e.g. Membership Admin>
- Purpose: <one-sentence purpose.>
- Scope of responsibility: <concrete responsibilities.>
- Decision authority: <which decisions in the Decision Matrix this role executes; explicit limits.>
- Interfaces: <other roles this role hands off to or receives from.>
- Eligibility criteria: <Full Member in good standing; any additional criteria.>
- Term / rotation: <ongoing / rotating / fixed term.>
- Appointment process: <how the role is assigned.>
- Review and removal: <how concerns are raised; reassignment via Strategic vote.>
- Handover: <what must be transferred before vacating.>
<Operational Role Name, e.g. Finance Steward>
- Purpose: <purpose.>
- Scope of responsibility: <responsibilities.>
- Decision authority: <Decision Matrix scope; spending limit.>
- Interfaces: <other roles.>
- Eligibility criteria: <Full Member in good standing.>
- Term / rotation: <...>
- Appointment process: <...>
- Review and removal: <...>
- Handover: <...>
<Add additional operational roles as needed (e.g. Infrastructure Steward, Communications Steward).>
What to cover
- Which operational roles do we need, and for each: what is it for and what is it responsible for?
- For each role: which decisions may it take without a community vote, and where are its limits (for example, a spending cap)?
- For each role: who is eligible, how long is the term, and how is the holder chosen?
- For each role: how, how often and by whom is the holder's work reviewed?
- For each role: what happens if the work is not getting done or the holder is overloaded — and how can the role be reassigned?
- For each role: what must be handed over before the holder leaves it?
Examples
Finance Steward: keeps the accounts, pays agreed bills and reports the balance monthly. May approve spending up to €500 per item within the budget; anything more needs a proposal. Any Full Member in good standing may stand for a two-year term, chosen by Strategic vote. The Operations meeting reviews the role every six months, and any member can raise a concern. If the holder is overloaded, the deputy takes over payments; persistent failure leads to reassignment by Strategic vote. Before leaving, the holder hands over bank access, open invoices and the reporting checklist.
Examples, not recommendations. Your answers will be your own.
Functional Roles
Which roles exist for a function rather than for daily work, and what are they for?
RCOS clauses 7.1.1, 7.1.2
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.
<Functional Role Name, e.g. Facilitator>
- Purpose: <purpose.>
- Scope of responsibility: <responsibilities.>
- Decision authority: <Full Member rights only.>
- Interfaces: <other roles.>
- Eligibility criteria: <Full Member; any additional preferences.>
- Term / rotation: <ongoing until vacated.>
- Appointment process: <self-declaration.>
- Review and removal: <may be vacated at any time; conflict-of-interest substitution per Layer 4 if relevant.>
- Handover: <active commitments to brief in.>
<Add additional functional roles as needed.>
What to cover
- Which functional roles do we have — for example facilitator, note-taker or welcomer — and what is each for?
- For each role: what does it do, and which other roles does it work with?
- For each role: who may take it on, and is saying ‘I'll do it’ enough?
- For each role: what does it not include — which decisions can it not make on the community's behalf?
- For each role: how does someone step down, and what must they brief the next person on?
Examples
Facilitator: prepares and runs meetings so everyone is heard and the agenda finishes on time. Any Full Member may take it on by announcing it in the members' channel; no vote is needed, and it carries no extra say in decisions. A facilitator who is a party to a conflict on the agenda steps aside for that item. They may step down at any time after briefing the next facilitator on upcoming meetings and open actions.
Examples, not recommendations. Your answers will be your own.
Ratification Record
- Adopted: <YYYY-MM-DD>
- Decision type: Strategic
- Version: <version>
- Decision record: <link to decision record>