Layer 1 · Membership
4 Membership State Registry
- Layer: 1 — Membership System
- Status: Stub — not yet adopted
- RCOS reference: §3.1, §3.8
Defined Membership States
RCOS definition3.1.1, 3.1.2, 3.1.3, 3.1.4, 3.1.5
- 3.1.1 The community MUST define explicit membership states.
- 3.1.2 At minimum, the following membership states MUST exist:
- 3.1.3 Each membership state MUST have clearly defined rights, obligations, and limitations.
- 3.1.4 No individual MAY hold multiple membership states simultaneously.
- 3.1.5 No rights or obligations MAY be assumed outside of the individual’s current membership state.
Why a single table of states?
Rights and obligations scattered across documents drift apart. Collecting every state, its rights, its obligations, and its transitions into one table makes the membership system auditable at a glance — you can see every door into and out of the community, and what each one grants. If two documents ever disagree, this registry is the tiebreaker.
| State | Can Vote | Can Propose | Can Hold Roles |
|---|---|---|---|
| <State — to be defined> |
Obligations for each State
| State | Governance Participation | Contribution requirements | Meeting attendance | Work contributions |
|---|---|---|---|---|
State transition triggers
| State | How to become | Possible Transitions |
|---|---|---|
No individual may hold multiple membership states simultaneously.
No rights or obligations may be assumed outside of the individual’s current membership state.
Technical Notes
Why preserve data after exit?
The community’s history belongs to the community, not to any individual account. Retaining contribution and participation records after exit protects the integrity of audit trails and governance history — while revoking access and removing the person from active listings respects the finality of their departure.
<Record retention and access rules after exit — to be defined.>
Ratification Record
- Adopted:
- Decision type: Strategic
- Version:
- Decision record: