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

Peeragogy in Practice

A specific project

⏱ 4 minPAT

Context

You find yourself interested in or concerned about something, but you only have a vague idea about how it works or how you fit in.

Forces

Difficulty: bringing about meaningful change is often hard work. Inertia: when things are hard we may feel stuck, wring our hands, or preach to the choir.

Problem

It’s easy to think about issues that matter: there are many of them. The problem is figuring out what you’re going to do about it. As a further problem, getting concrete can be scary, because you risk failure.[fn:1]

Solution

If you are able to get concrete about something to do, learn, and achieve, you move from thinking about a topic to becoming a practitioner. You may realize that your “specific project” is too large to tackle directly. In this case, you will have to become even more specific. Maintaining a project Roadmap can help keep track of the smaller pieces and the bigger picture.

Rationale

Being specific is important for bringing about change.[fn:2] But while actions speak louder than words, it’s important to act in a coherent way if you want to be understood by others. However, in general it would be a mistake to try to seek consensus before acting: it’s much better to combine action with dialog.

What’s Next

Each project connected with the Peeragogy Project should be described with one or more patterns, each with specific, tangible “what’s next” steps.[fn:3] The Pattern Audit Routine can help make these “what’s next” steps concrete.

Furthermore, each project, insofar as it uses patterns in the style we’ve discussed, should have an emergent roadmap comprised of ‘next steps’. Here’s ours:

BACK Version 4 of the Handbook :handbook:

  • As of 0115 our target for completion was 0731

BACK Get contributors lined up & committed: contact, spreadsheet :handbook:

PATT Can each podcast become a handbook chapter or mini-handbook? :podcast:handbook:

  • Pete Forsythe is doing several different podcasts so that’s likely to be enough for a chapter

BACK Adaptation of paper for book :paper:

BACK Docs about PARs to be circulated more widely :paper:

[fn:1] In the Peeragogy project and more broadly, we’ve observed that some people are happy with a sense of experience or process, while others want to see results. Some others are in the middle. All of these variations are OK! However, we are often blinded by our own preferences, and in the worst case this can undermine or destroy group dynamics. At the very least it will add tension, as some want to continue to discuss and engage generally while others want to move forward. When the forward-movers try to act, those enjoying the experience may attempt to shut them down or may feel that they are being left out/behind.

[fn:2] In the January, 2013, plenary session, Independent Publishers of New England (IPNE) President Tordis Isselhardt quietly listened to a presentation about how we created the Peeragogy Handbook. During the Q&A, she spoke up, wondering if peer-learning effort in IPNE might be more likely to succeed if the organization’s members “focused around a specific project.” As this lightbulb illuminated the room, those of us attending the plenary session suggested that IPNE could focus the project by creating an “Independent Publishing Handbook.” (Applause!) In the course of creating the IPNE Handbook, peer learners would assemble resource repositories, exchange expertise, and collaboratively edit documents. To provide motivation and incentive to participate in “PeerPubU”, members of the association will earn authorship credit for contributing articles, editor credit for working on the manuscript, and can spin off their own chapters as stand-alone, profit-making publications.

[fn:3] We’ve found that writing papers for conferences is one activity that can help us focus and make improvements to our body of work that would not come about by simply meandering through revisions to the Peeragogy Handbook. Remixing these efforts into the handbook is a good source of improvements; see Use or Make.

⚡ Unpeeragogy · Friction · Observation

Specific Cases Don't Generalize

⏱ 4 minaudit-v2specificcontextadaptation

Perturbatore: “What if every consultant says ‘it depends on your context’ — that’s not wisdom, that’s a billable hour — and the adaptation that matters is structural, not attitudinal?”

Document what will not change. Not what might.

The Assumption

Patterns must be adapted to specific contexts rather than applied universally. Assuming a pattern works without testing it in your context can lead to failure.

Operational Reality

Every consultant says “it depends on your context” — that is not wisdom, that is a billable hour.

The pattern is trivially true and practically useless. Of course context matters. The question is how to adapt. GitLab’s stewardship handbook does not advise “adapt to context” — it documents specific governance boundaries that transfer across contexts. OpenStreetMap’s Data Working Group does not recommend “test in your environment” — it publishes enforceable dispute resolution mechanisms. WebAssembly’s lighter governance model shows that even intentional context-specific choices have predictable failure modes. Drupal’s governance transition demonstrates that context adaptation without governance design produces the same failure modes regardless of context.

The pattern mistakes truism for insight. The adaptation that matters is structural, not attitudinal. Document what will not change, not what might.

Empirical Evidence

Resilience Cases (Confirming):

  • GitLab Stewardship Handbook — Explicit documentation of governance boundaries between corporate sponsor and community reduces friction. Cross-context adaptation works when governance boundaries are explicitly documented, not when adaptation is advised generically.
  • OpenStreetMap Data Working Group — Formal dispute resolution bodies with binding authority and published reasoning resolve peer production conflicts. Portable governance mechanisms outperform context-specific advice.

Fracture Cases (Complicating):

  • WebAssembly Community Group — Choosing lighter governance models for standards development trades authority for speed, creating different failure modes. Even intentional context-specific choices have predictable failure modes.
  • Drupal Governance — Intentional governance transition from BDFL to community model required years of structural work. Context adaptation without governance design produces the same failure modes regardless of context.

Operational Heuristics

Positive Boundary: Contextual adaptation works when it includes explicit documentation of governance boundaries and formal mechanisms for handling edge cases — portable mechanisms outperform context-specific advice.

Negative Boundary: Do not apply this pattern by merely advising “adapt to your context” without defining adaptation mechanisms — even intentional context-specific choices have predictable failure modes.

Epistemic Synthesis

The pattern is trivially true and practically useless. Of course context matters. The question is how to adapt. GitLab does not advise “adapt to context” — it documents specific governance boundaries that transfer across contexts. OpenStreetMap publishes enforceable dispute resolution mechanisms. The adaptation that matters is structural, not attitudinal. Document what will not change, not what might.

Evidence Status

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

Traceability

Run: audit-v2 · Delta: 1.2 → 1.22 (±0.02) · Diversity D: 2

References

💬 Field Report: Specific Cases Don't Generalize

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.