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

Peeragogy in Practice

Emergent roadmap

⏱ 6 min

Collecting the “What’s Next” steps from the previous patterns, here’s our current “distributed roadmap” for the Peeragogy project.

Carrying Capacity:

This pattern catalog has been rewritten in a way that should make it easy for anyone to add new patterns. Making it easy and fruitful for others to get involved is one of the best ways to redistribute the load (compare the Newcomer pattern).

Creating A Guide:

We’ve been talking with collaborators in the Commons Abundance Network about how to make a Pattern Language for the Commons. One of the challenges that arises is how to support ongoing development of the Pattern Language itself: a “living” map for a living territory. We’re refining the Peeragogy Pattern language and template as a seed for this.

Discerning A Pattern:

What do the patterns we’ve observed say about the self-selection processes of the group? For instance, it’s possible that a widespread interest in organic gardening, say, may indicate the participants are oriented to cooperation, personal health, or environmental activism. What can we learn about the Peeragogy project from our collected patterns?

Heartbeat:

When the project is bigger than more than just a few people, it’s likely you’ll get several heartbeats – for instance, we’ve recently been running two weekly meetings in the Peeragogy project, for members with slightly different interests and slightly different availability. Finding ways to communicate across these different “camps” is useful.

Isolation:

We recently submitted an abstract called “Escape from Peeragogy Island” to a geography conference talking about the spatiality of peer production. The idea behind this article is that we feel like we’ve come up with something great with the Peeragogy project, but we’re going to be a bit isolated if it’s not transparently useful to others. If we can’t explain why it’s a great idea, then it’s not entirely clear how great of an idea it actually is.

Magical Thinking:

Fast-forwarding a few years from the DIY Math experiment: as part of the PlanetMath project, we are hoping to build a well-thought-through example of a peer learning space for mathematics. One of the ideas we’re exploring is to use patterns and antipatterns (exactly like the ones in this catalog) as a way not only of designing a learning space, but also of talking about the difficulties that people frequently run into when studying mathematics. Building an initial collection of Calculus Patterns may help give people the guide-posts they need to start effectively self-organizing.

Messy With Lurkers:

What comes out of thinking about the anti-pattern is that we need to be careful about how we think about “virtues” in a peer production setting. It is not just a question of being a “good contributor” to an existing project, but of continually improving the methods that this project uses to make meaning.

Misunderstanding Power:

As Paul Graham wrote about programming languages – programmers are typically “satisfied with whatever language they happen to use, because it dictates the way they think about programs” – so too are people often “satisfied” with their social environments, because these tend to dictate the way they think and act in life. Nevertheless, if we put our minds to it, we can become more “literate” in the patterns that make up our world and the ways we can effect change.

Moderation:

We recently ran a Paragogical Action Review to elicit feedback from participants in the Peeragogy project. Some of them brought up dissatisfactions, and some of them brought up confusion. Can we find ways to bring these concerns front-and-center, without embarrassing the people who brought them up?

Navel Gazing:

We have hinted that, in this project, effective criticism is very welcome! But understanding what makes criticism effective is, in general, still a research problem.

Newcomer:

We recently revised the “How to Get Involved” page, listing the top ten sites we use. Another reasonable thing to post would be a top-ten list of activities, so that people can get an easier view on the kinds of things we do in the project.

Polling For Ideas:

We’ve considered asking new members of the project to do an “entry survey” as part of joining the project, to describe their aims and understanding of what they hope to contribute. This could establish a context of contribution, and help new members to feel like full “peers”.

Praxis Vs Poeisis:

“Platform” debates can be frustrating but can also add something to a project in the long term, since they help people become aware of their priorities. As mentioned in the Newcomer pattern, developing a more clear picture of the activities that we engage in in the project will help make it comprehensible to others. It will also be useful for us to have a clearer picture of what we do, and what we make.

Roadmap:

Adding “What’s Next” steps to our patterns gives us a “distributed roadmap.” And this works both ways: If we sense that something needs to change about the project, that’s a clue that we might need to record a new pattern.

Roles:

We’ve listed some of the roles for which we’re seeking volunteers in the Peeragogy.org Roadmap: Volunteer Coordinator, Seminar Coordinator, Usability Guru, Activities Master, and Tech lead. As with everything else in the roadmap, this list should be reviewed and revised regularly, as the roles are understood relative to the actual happenings in the Peeragogy project.

Specific Project:

In the third year of the Peeragogy project, rather than just keep working on the handbook, we’ve been working on building a Peeragogy Accelerator, as a peer support system for projects related to peer learning and peer production. Not only does specificity help member projects, being clear about what the Accelerator itself is supposed to do will help people get involved.

Stasis:

We’re working on a new handbook chapter about the relationship of open source software and peeragogy. This will include some more specific ideas about ways of making change.

Stuck:

If we are actively engaging with other people, then this is a foundation for strong ties. In this case of deep learning, our aims are neither instrumental nor informational, but “interactional”. Incidentally, the “One of us” quoted above has been one of the most consistently engaged peeragogues over the years of the project. Showing up is a good step – you can always help someone else move their washing machine!

Wrapper:

We need better practices for wrapping things up at various levels. One of the latest ideas is to develop a simple visual “dashboard” for the project.

⚡ Unpeeragogy · Friction · Observation

What's Next Is Nowhere

⏱ 4 minaudit-v2whats-nextfutureroadmap

The Assumption

Future direction statements for the Peeragogy Handbook — outlining planned updates, community growth targets, and resource allocation — presented as transparent roadmap and collective ambition.

Perturbatore: “What if ‘next steps’ is what people write when they don’t know what to do next — and direction documents without governance produce statements too vague to follow or contest?”

Direction is not the problem. Missing governance is.

Operational Reality

“Next steps” is what people write when they do not know what to do next.

GitLab’s stewardship handbook shows that explicit governance boundaries produce sustainable direction — not “next steps” documents. Fedora FESCo demonstrates that elected roles with defined scope enable transparent roadmap decisions. But Debian’s DPL newsletter shows that direction documents without governance produce statements too vague to follow or contest. Wikipedia’s ArbCom shows that even transparent communities fracture when future direction is contested without binding authority.

The pattern is not wrong. It is premature. The direction is not the problem — the missing governance that would make direction meaningful is the problem.

Empirical Evidence

Resilience Cases (Confirming):

  • GitLab Stewardship Handbook — Explicit documentation of governance boundaries between corporate sponsor and community reduces friction. Governance boundaries produce sustainable direction more effectively than direction documents.

Fracture Cases (Complicating):

Operational Heuristics

Positive Boundary: Future direction works when governance boundaries are documented explicitly and authority roles are defined before strategic planning — elected technical roles with defined scope enable transparent roadmap decisions.

Negative Boundary: Do not rely on “next steps” documents as a governance mechanism — direction documents without governance produce statements too vague to follow or contest.

Epistemic Synthesis

“Next steps” is what people write when they do not know what to do next. GitLab shows that governance boundaries produce sustainable direction. Fedora shows that elected roles with defined scope enable transparent roadmap decisions. The pattern is not wrong. It is premature. The direction is not the problem — the missing governance that would make direction meaningful is the problem.

Evidence Status

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

Traceability

Run: audit-v2 · Delta: 1.3 → 1.055 (±0.245) · Diversity D: 2

References

💬 Field Report: What's Next Is Nowhere

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.