Roles

Definition:

Educational interactions tend to have a number of different roles associated with them. Everything could bifurcate from the “autodidact”, as in, (1) Autodidact, (2) Tutor-Tutee, (3) Tutor-Tutee-Peer, etc., until we have bursars, librarians, technicians, janitors, editors of peer reviewed research journals, government policy makers, spin-off industrial ventures and partnerships, and so on.

Problem:

Even the autodidact may assume different roles at different points in time - sometimes building a library, sometimes constructing a model, sometimes checking a proof. The decomposition of “learning” into different phases or polarities could be an endless theoretical task. The simpler problem is to be aware of the roles that you and your teammates have in the projects you’re working on.

What’s Next:

We’ve listed some of the roles for which we’re seeking volunteers in thePeeragogy.org Roadmap: Volunteer Coordinator, Seminar Coordinator, Usability Guru, Activities Master, and Tech lead. As with everything else in the roadmap, this list should be reviewed and revised regularly, as the roles are understood relative to the actual happenings in the Peeragogy project.

The Assumption

Roles in peer learning should be fluid and rotational to prevent hierarchy formation and maintain equality among participants.

Perturbatore: “What if rotating the deck chairs doesn’t sink the Titanic any slower — and fluid roles feel egalitarian but are also unaccountable?”

Rotating the chairs does not stop the ship from sinking.

Operational Reality

Rotating the deck chairs does not sink the Titanic any slower.

The pattern assumes fluid roles prevent hierarchy. They do not. They just make hierarchy invisible — harder to see, harder to challenge, harder to name. Fedora’s Engineering Steering Committee shows that elected roles with defined scope and public records maintain peer governance precisely because the hierarchy is explicit and bounded. The Linux kernel’s maintainer burnout shows that unlimited peer responsibility creates failure points that rotation alone cannot address. Lido DAO demonstrates that even blockchain-based peer governance centralizes when fluid roles meet real decisions.

Fluid roles feel egalitarian. They are also unaccountable. The person who chaired last month’s meeting is not responsible for last month’s decision.

Empirical Evidence

Resilience Cases (Confirming):

Fedora Engineering Steering Committee — Elected technical steering committees with defined scope and transparent records provide sustainable peer governance. Transparent hierarchy enables peer production.

Fracture Cases (Complicating):

Linux Kernel Maintainer Burnout — Unlimited peer responsibility creates failure points that rotation alone cannot address. Fluid responsibility without bounded authority produces burnout.
Lido DAO Governance — Even blockchain-based peer governance centralizes when fluid roles meet real decisions. Explicit hierarchy is more accountable than invisible hierarchy.

Operational Heuristics

Positive Boundary: Roles work when authority scope is explicitly bounded and transparent — elected technical roles with defined scope and public records maintain peer production.

Negative Boundary: Do not apply fluid roles when decisions require specialized knowledge or carry long-term maintenance burden — unlimited peer responsibility creates failure points; maintainer burnout is a governance risk, not an individual one.

Epistemic Synthesis

Fluid roles do not prevent hierarchy — they make it invisible. Fedora shows that explicit, bounded hierarchy enables peer production. Linux shows that unlimited responsibility produces burnout regardless of rotation. Lido shows that even blockchain governance centralizes when fluid roles meet real decisions. The chair of last month’s meeting is not responsible for last month’s decision. That is the cost of fluidity.

Evidence Status

Status	Count
Confirmed cases	1
Cases under study	0
Unverified cases	0
Ambiguous cases	0

Traceability

Run: audit-v2 · Delta: 1.5 → 1.6467 (±0.1467) · Diversity D: 2

References

💬 Field Report: Roles Are the Invisible Hierarchy

Every pattern in the Handbook has been tested in the real world — and the real world usually has something to say about it. If you tried something similar, or saw it fail differently, share the story here.

Write in your native language — the browser will translate. Lowering the entry barrier is more important than choosing the "right" language. GitHub translates threads automatically so everyone can follow along.
Read how evidence is collected →

What happens after I share my story?

1. Your post appears in GitHub Discussions in the Field reports category.

2. Once a week, the project reads new threads and checks for patterns worth integrating.

3. If your story reveals a new Failure Vector, a revision to tension_index, or a sharper edge for the Perturbator — the entry gets updated.

4. The change is logged at /log and goes live on the next deploy.

Don't have a GitHub account? Here's how it works

GitHub Discussions is free. You need a GitHub account (30 seconds to create one).

Once you're signed in, click "Share your story" above. Write in your own language — the thread will be translated for everyone else automatically.

You don't need to know how to code. You don't need to know what "git" is. You just need an observation that the theory didn't match reality.

What are GitHub Discussions? →