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

Resources

About

⏱ 1 minAN

The Peeragogy project was convened by Howard Rheingold in 2012 (https://clalliance.org/blog/toward-peeragogy/). Here is a video in which Howard describes how he went from organising co-teaching in his classes at Berkeley and Stanford, to running collaborative courses online, to convening a group of people to collect practical know-how about how to learn any subject without teachers: https://youtu.be/dHvGIX2Wjss?t=138

The Peeragogy Handbook is the “the no-longer-missing guide to peer learning & peer production.” We decided to early on to publish our book directly in to the public domain, via the CC Zero waiver, so that we could minimise friction for people adopting and adapting the contents (http://www.peeragogy.org/license). We are currently working on the 4th Edition of the book, which will bring a lot of changes to the contents (the 3rd Edition was published in 2016).

⚡ Unpeeragogy · Friction · Observation

About Is for Outsiders

⏱ 4 minaudit-v2aboutintroductionmission

Perturbatore: “What if an About page that does not name current decision-makers is not welcoming newcomers — but warning them away?”

The Assumption

The About page serves as the primary entry point for newcomers. If the page clearly states what peeragogy is and what it offers, the right people will find their way in. Information clarity produces engagement.

Operational Reality

Howard Rheingold convened the Peeragogy project in 2012. Years later, the About page still opens with his name. The handbook speaks of collaborative courses and collected know-how, but governance remains a footnote. Not a conspiracy. Not malice. Not even conscious choice — just the default drift toward founder mythology in projects that never establish explicit governance.

Founder mythology does not need malice. It needs inattention.

Open-core projects that document governance boundaries between corporate sponsors and communities reduce friction. The boundaries are visible. People know where they stand. Projects that claim pure peer governance while maintaining informal hierarchies create something more dangerous — the illusion of equality with the reality of invisible barriers.

GitLab documents exactly who decides what, and collaboration works because the boundaries are explicit before conflict arrives. Drupal shows that transitioning from BDFL to community governance requires years of structural work — an About page cannot solve a governance problem by renaming it. Apache shows that meritocracy-based governance creates invisible hierarchies through time-availability bias: the page that looks most open may trap newcomers most effectively.

Empirical Evidence

Resilience Cases (Confirming):

  • GitLab Stewardship Handbook — Explicit documentation of governance boundaries between corporate sponsor and community reduces friction. Transparent documentation of who decides what makes collaboration sustainable.

Fracture Cases (Complicating):

  • Drupal Governance — Governance transition from BDFL to community model required years of structural work. Governance transparency is not a communication problem but a structural one requiring explicit redesign.
  • Apache Foundation How It Works — Meritocracy-based governance creates invisible hierarchies through time-availability bias. The page that looks most open may trap newcomers most effectively.

Operational Heuristics

Positive Boundary: Document both learning principles and governance boundaries explicitly on the About page — transparent decision-making boundaries reduce friction for newcomers.

Negative Boundary: Do not create About pages that explain learning principles without documenting power structures — meritocratic governance creates invisible class systems, and a page that hides them is a trap, not a welcome.

Epistemic Synthesis

The theory assumes that communication clarity produces engagement. The evidence shows governance structure matters more than page clarity. The About page problem is not being “too detailed” but presenting peeragogy as if it emerges naturally from good intentions instead of requiring explicit structures to function. GitLab, Drupal, and Apache each show that the meaningful information gap is not about the mission — it is about who decides what.

Evidence Status

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

Traceability

Run: audit-v2 · Delta: 1.0 → 1.1217 · Diversity D: 2

References

💬 Field Report: About Is for Outsiders

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.