📖 Source→⚡ Observation·Where the pattern works/Where the pattern breaks·Interpretation ≠ Conclusion

Resources

course

⏱ 1 minSUB

It’s not peeragogy unless it’s collaborative: simultaneously, we can’t expect people to “get it” unless we co-create opportunities to “do with us”.

A set of interactive exercises that help people wrap their hearts and minds around peeragogy can help us understand if it’s working.

In the context of ‘education’ this may be a renegade activity; in workplace cultures, open learning may also be unfamiliar. But peeragogy thrives in open source settings!

One of the reasons for writing the Peeragogy Handbook v4 is that we didn’t think that the predecessor was actually sufficiently used (or sufficiently useful, if we’re honest). We included a short syllabus we called Peeragogy in action, but it didn’t seem to catch on. So we figured we should deliver a course about Peeragogy ourselves somewhere, using the Handbook as the course text. At first we were looking around for the right venue, but we also figured we could just pilot the course ourselves any time. So we’ve been working on that.

Next steps

  • For now “course” is one of the tags used on peeragogy.org, but it should probably develop into its own pattern.

⚡ Unpeeragogy · Friction · Observation

The Course Doesn't Teach

⏱ 4 minaudit-v2coursetrainingcommunity

The Assumption

Courses are structured learning experiences that can fail when they lack clear organization or when expectations are misaligned with the peer learning model. Better course design — clearer objectives, better facilitation, tighter feedback loops — produces better peer learning outcomes.

Operational Reality

The workshop materials exist — timelines, peer feedback loops, structured activities. But the learning happens in the gaps between what the facilitator provides and what participants need to figure out. Not because the facilitator is withholding information. Not because discovery learning is pedagogically superior. Not because of some romantic vision of self-directed growth. Because the moment the facilitator starts teaching, participants stop learning how to learn from each other.

Perturbatore: “What if every course designer thinks they have found the sweet spot between structure and freedom — but most have just found the sweet spot between two different kinds of failure?”

Courses do not fail. They stabilize the wrong kind of learning.

Courses in peer learning serve a paradoxical function: the formal structures — learning objectives, facilitation protocols, assessment rubrics — serve institutional needs more than learning. The course creates the conditions for peer learning, but does not create the learning itself. Too much structure and people delegate to the system. Too little and they drown. The point is not an equilibrium — it is a productive instability where participants cannot stabilize in passive consumption.

P2PU demonstrates that structured facilitation with institutional backing creates conditions where peer learning can survive. OpenStreetMap shows that structured authority mechanisms — not course design — resolve the conflicts that kill peer learning. WebAssembly reveals that the sweet spot between structure and freedom is always a trade-off, never a solution. The IETF demonstrates that pure peer governance without escalation fails — not because of poor course design, but because consensus without appeals is governance by attrition.

Empirical Evidence

Resilience Cases (Confirming):

  • P2PU Learning Circles — Peer learning models with defined facilitator roles and institutional partnerships are more sustainable than purely peer-driven learning. Structured facilitation with institutional backing creates conditions where peer learning can survive.
  • OpenStreetMap Data Working Group — Formal dispute resolution bodies with binding authority and published reasoning resolve peer production conflicts that informal consensus cannot. Structured authority mechanisms — not course design — resolve the conflicts that kill peer learning.

Fracture Cases (Complicating):

  • WebAssembly Community Group — Choosing lighter governance models for standards development trades authority for speed, creating different failure modes. The sweet spot between structure and freedom is always a trade-off, never a solution.
  • IETF Working Group Rough Consensus — Rough consensus governance only works when backed by hierarchical escalation paths. Pure peer governance without escalation fails — consensus without appeals is governance by attrition.

Operational Heuristics

Positive Boundary: Design courses as productive instability systems where the container is explicit but the learning path is not — P2PU demonstrates that institutional backing and defined facilitator roles create the conditions for peer learning without replacing it.

Negative Boundary: Do not design courses assuming pure peer governance suffices when they involve contested technical decisions or resource allocation — IETF and WebAssembly demonstrate that consensus without escalation paths fails; course design does not resolve this structural tension.

Epistemic Synthesis

The evidence suggests something uncomfortable: the formal structures we build — learning objectives, facilitation protocols, assessment rubrics — serve institutional needs more than learning. The course creates the conditions for peer learning, but does not create the learning itself. Too much structure and people delegate to the system. Too little and they drown. The point is not equilibrium — it is a productive instability where participants cannot stabilize in passive consumption.

Evidence Status

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

Traceability

Run: audit-v2 · Delta: 1.3 → 1.3319 (±0.0319) · Diversity D: 2

References

💬 Field Report: The Course Doesn't Teach

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? →

Every pattern raises more questions than it answers.
Read the theory. Then look at what happened.