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

Peeragogy in Practice

Patterns

⏱ 6 min

Although a grounding in learning theory helps inform peer learning projects, Peeragogy, at its core, comes to life in applied practice. Even before convening a group for your peer learning project (discussed in [[http://peeragogy.github.io/convening.html][Part IV]]), you will want to take a look over the patterns we have collected. You will likely return here many times as your project develops.

What is a pattern?

A pattern is anything that has a repeated effect. In the context of peeragogy, the practice is to repeat processes and interactions that advance the learning mission. Frequent occurrences that are not desirable are called anti-patterns!

Christopher Alexander: “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in a way that you can use this solution a million times over, without ever doing it the same way twice.” [1]

Patterns provide a framework that can be applied to similar issues but may be metaphorically solved in different ways, sometimes in real world or face to face events and other times in digital space. Outside of Alexander’s own work in architecture, one the first groups to adopt a design pattern way of thinking about things were computer programmers. Writing in the foreward to Richard P. Gabriel’s Patterns of Software, Alexander emphasizes that the key question to ask about any design approach is: does it help us build better?

Christopher Alexander: “What is the Chartres of programming? What task is at a high enough level to inspire people writing programs, to reach for the stars?” [2]

We think that Peeragogy stands a good chance of being a “killer app” for pattern-based design. Learning bridges physical and virtual worlds all the time. And, in fact, a Network of Learning was the 18th pattern that Christopher Alexander introduced in his book, A Pattern Language.

Christopher Alexander: “Work in piecemeal ways to decentralize the process of learning and enrich it through contact with many places and people all over the city: workshops, teachers at home or walking through the city, professionals willing to take on the young as helpers, older children teaching younger children, museums, youth groups travelling, scholarly seminars, industrial workshops, old people, and so on.” [1]

Peeragogy can help to extend and enrich this network, and, as we shall see, patterns can be used by those involved to do ongoing “emergent” design, not only by building new structures, but by adapting and improving our catalog of patterns as we go. For consistency, and easy use, adaptation, and extension we present the patterns using the following template. The format is meant to be neutral and easy to work with – it’s, intentionally, an outline that you might use to write a short abstract describing an active project.

Title: /Encapsulate the idea - possibly include a subtitle/

Context: /Describe the context in which it is meaningful. What are the key forces acting in this context?/

Problem: /Explain why there’s some issue to address here./

Solution: /Talk about an idea about how to address the issue./

Rationale: /Why do we use this solution as opposed to some other solution?/

Resolution: /How are the key forces resolved when the solution is applied?/

What’s Next: /Talk about specific next steps. How will the active forces continue to resolve in our project?/

Patterns include the following optional elements:

[Examples: /Present example(s) that have been encountered, if this aids comprehension./]

[References: /Citations, if relevant./]

The “What’s Next” section concretely links the patterns we discuss here to the Peeragogy project. It can be thought of as an annotation rather than part of the pattern itself. If you adapt the patterns for use in your own project, you’re likely to have a different set of next steps. Although we think that these patterns can be generally useful, they aren’t useful in the abstract, but rather, as a way for discussing what we actually do.

A peeragogy pattern language

By looking at how patterns combine in real and hypothetical use cases, you can start to identify a pattern language that can be used in your projects. We can get a simplified view of these connections with the following diagram. It’s important to clarify that everyone doesn’t do it the same way. Here, the Roadmap is given a central position, but some peer learning projects will forego making a specific, detailed plan; their plan is just to see what develops. You can see here how peeragogy patterns often break down further into individual micro-steps: we’ll say more about that shortly.

[can this chart be larger? Looks very small in text] The subsequent main sections of this book – /Convene/, /Organize/, /Cooperate/ and /Assess/ (for short) – represent big clusters of patterns that are likely to come up time and again in various projects. We can think of these as East, South, West, and North in the diagram above. You are encouraged to invent your own patterns and to connect them in new ways. You’ll probably find quite a few that we didn’t include in the catalog. Each project has a unique design, and it’s own unique way in which things play out in practice. What we’ve put together here is a starter kit. The peeragogy patterns suggest a social way to do problem solving [3], but once you get used to the pattern concept you can use it to identify new problems no one has ever thought of before, and that’s even more powerful!

Next steps

BACK Outline a good pattern paper for PLoP 2021? :paper:

  • We need to figure out how to think about it!

BACK Ray and Joe need to get the deadline and writing process up and running:paper:

BACK Integrate what we said about patterns in the anticipation paper here :paper:

References

  1. Alexander, C., Ishikawa, S., and Silverstein, M. (1977). /A Pattern Language: Towns, Buildings, and, Construction/, New York: Oxford University Press.

  2. Gabriel, Richard P. (1996). Patterns of Software, New York: Oxford University Press. (Includes a foreward by Christopher Alexander.)

  3. Minsky, Marvin. (2008–2009). Essays on Education (for OLPC), Massachusetts Institute of Technology Media Lab whitepaper, Available online.

⚡ Unpeeragogy · Friction · Observation

Patterns Are Not Recipes

⏱ 4 minaudit-v2patternshypothesisgovernance

The Assumption

The Peeragogy Handbook describes patterns as hypotheses rather than guaranteed solutions, acknowledging they may fail when context or people change, yet users seek prescriptive guidance rather than descriptive frameworks.

Operational Reality

Drupal spent years transitioning from BDFL to community governance. Not because the BDFL pattern was wrong. Not because the community governance pattern was right. Because no pattern survives first contact with organizational legacy without structural work.

The handbook describes patterns as hypotheses. This is intellectually honest — patterns work in some contexts, fail in others, and evolve with use. But groups seeking guidance do not want a hypothesis. They want to know what to do on Tuesday. The honest description fragments into advice that sounds like authority without actually having it.

GitLab’s stewardship handbook does not describe governance as hypothesis. It documents boundaries: here is what the corporation controls, here is what the community controls, here is how conflicts are resolved. The patterns are embedded in operational reality, not offered as possibilities. Wikipedia’s Good Article process demonstrates that pattern implementation requires structural scaffolding — not just pattern recognition. ArbCom demonstrates that the governance scaffolding around patterns is more predictive of success than the patterns themselves.

Perturbatore: “What if a hypothesis that never becomes a commitment is just procrastination with footnotes — and the difference between a pattern that works and one that does not is not the pattern, but the scaffolding around it?”

Empirical Evidence

Resilience Cases (Confirming):

  • GitLab Stewardship Handbook — Explicit documentation of governance boundaries between corporate sponsor and community reduces friction in open-core projects. Patterns embedded in operational boundaries work better than patterns offered as hypotheses.
  • Wikipedia Good Article Process — Peer assessment with transparent criteria and independent reviewers creates sustainable quality tiers. Pattern implementation requires structural scaffolding — not just pattern recognition.

Fracture Cases (Complicating):

  • Drupal Governance — Intentional governance transition from BDFL to community model required years of structural work. Even successful pattern changes require intentional governance work — patterns as hypotheses do not self-implement.
  • Wikipedia Arbitration Committee — Permanent records of community conflicts that consensus failed to resolve. The governance scaffolding around patterns is more predictive of success than the patterns themselves.

Operational Heuristics

Positive Boundary: Patterns work when governance boundaries are explicit and evaluation criteria are transparent — documented governance structures create sustainable pattern implementation across different contexts.

Negative Boundary: Do not apply patterns without governance scaffolding — even successful pattern changes require intentional structural work; organic emergence fails when coordination complexity exceeds informal relationships.

Epistemic Synthesis

The difference between a pattern that works and one that does not is not the pattern — it is the scaffolding around it. GitLab does not propose stewardship as a hypothesis — it documents operational boundaries. Drupal did not change pattern by consensus — it worked for years on structural transitions. Patterns as hypotheses are intellectually honest but operationally useless. What groups seek are not possibilities — they are boundaries within which to operate.

Perturbatore: “What if a hypothesis that never becomes a commitment is just procrastination with footnotes — and the difference between a pattern that works and one that does not is not the pattern, but the scaffolding around it?”

The scaffold matters more than the wall it supports.

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.3533 (±0.0467) · Diversity D: 2

References

💬 Field Report: Patterns Are Not Recipes

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.