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

Peeragogy in Practice

Solution

⏱ 3 min

Our solution builds on these methods: Patterns, Next Steps, PARs, and CLAs.

Solution as pattern

  • Every solution also has a problem: the problem it solves.
  • Once there’s a solution, the problem ceases to be a problem. If you start with the problem you’ll have to find the solution?
  • Even the solution, which developed through time and enterprise, stops being thought of as a solution as the problem fades into the background.

The primary aspects of the solution that we will present here are:

  • to Convene a relevant group of people
  • to Organize them in a meaningful way
  • to Cooperate on aspects of the problem
  • to Assess progress together as you go, and
  • to Share your findings with others, both as you go and whenever you’re done.

This might sound abstract but we will show how these methods come together to solve serious problems.

Notice that this outline mirrors the five parts of the PAR, which instantiates a micro- version of ‘peeragogy’ and which also, usefully, produces data that we can integrate later on, in later rounds of convening, organising, etc.

The PAR has the following steps:

  1. Review the intention: what do we expect to learn or make together?
  2. Establish what is happening: what and how are we learning?
  3. What are some different perspectives on what’s happening?
  4. What did we learn or change?
  5. What else should we change going forward?

A quick word about patterns

In the major sections of the book, we will present our ‘solution’ to various problems using patterns that we’ve encountered time and time again in the Peeragogy project.

You can use the patterns as a starter-kit for your own experiments with peeragogy. Sharing – and revising – patterns is one of the key activities we do in the peeragogy project, and you will likely want to revisit this chapter several times as you look through the rest of the book. Don’t forget your pen or pencil to tailor the patterns to your own needs; or, if you have the opportunity, jump into the discussion online to improve the patterns for others.

Next steps

BACK ‘Patternize’ the major sections :handbook:

Each of the major subsections — Convening, Organizing, Cooperation, Assessement, and Share — should be turned into a pattern.

BACK Merge existing patterns as subsections of the major sections :handbook:

All of our existing patterns should fit into the major subsections as sub-patterns. (If they don’t fit well, then we should add more major sections!)

⚡ Unpeeragogy · Friction · Observation

The Solution Is Not a Pattern

⏱ 4 minaudit-v2solutionapproachcollective

Perturbatore: “What if peer-driven solutions work great until someone has to make a decision that pisses people off — and the missing piece is the authority to end solution-seeking and commit?”

Peer solutions work until someone has to piss people off.

The Assumption

Solution-oriented approaches where peer learning groups identify problems collectively and develop responses through shared facilitation and distributed leadership.

Operational Reality

Peer-driven solutions work great until someone has to make a decision that pisses people off.

P2PU’s learning circles succeed through institutional partnerships that provide legitimacy when peer decisions need enforcement. GitLab’s stewardship handbook documents explicit governance boundaries that activate when consensus fails. But IETF’s rough consensus model shows that pure peer solution-seeking fails when decisions are contested — the escalation path is invisible until it is needed. Wikipedia’s ArbCom exists because peer solutions without binding authority produce endless debate.

The pattern assumes collective problem-solving is sufficient. The evidence shows it is necessary but not sufficient. The missing piece is the authority to end solution-seeking and commit.

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. Institutional legitimacy enables peer solution enforcement.
  • GitLab Stewardship Handbook — Explicit documentation of governance boundaries between corporate sponsor and community reduces friction in open-core projects. Documented governance boundaries activate when peer solutions reach consensus limits.

Fracture Cases (Complicating):

  • IETF Rough Consensus — Rough consensus governance only works when backed by hierarchical escalation paths. Pure peer solution-seeking fails when decisions are contested.
  • Wikipedia Arbitration Committee — Peer solutions without binding authority produce endless debate. Peer governance requires a formal judicial layer.

Operational Heuristics

Positive Boundary: This pattern works when institutional partnerships provide legitimacy and resources, or when explicit governance boundaries define decision-making authority — peer solution-seeking needs enforcement mechanisms.

Negative Boundary: Do not apply this pattern for high-stakes or contested decisions without clear escalation mechanisms — pure peer consensus fails when decisions are contested.

Epistemic Synthesis

Collective problem-solving is necessary but not sufficient. The missing piece is the authority to end solution-seeking and commit. P2PU and GitLab show that peer solution-seeking needs enforcement. IETF and Wikipedia show that it fails when decisions are contested. Peer-driven solutions work until someone has to make a decision that pisses people off.

Evidence Status

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

Traceability

Run: audit-v2 · Delta: 1.4 → 1.22 (±0.18) · Diversity D: 2

References

💬 Field Report: The Solution Is Not a Pattern

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.