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

Organizing a Learning Context

Adding Structure

⏱ 5 min

In the introduction to “Organizing a Learning Context”, we remarked that a “learning space” is only potentially less structured than a “course”.  For example, a library tends to be highly structured, with quiet rooms for reading, protocols for checking out books, a cataloging and shelving system that allows people to find what they are looking for, as well as rules that deter vandalism and theft. (Digital libraries don’t need to play by all the same rules, but are still structured.)

But more structure does not always lead to better learning. In a 2010 Forbes article titled, “The Classroom in 2020,” George Kembel describes a future in which “Tidy lectures will be supplanted by messy real-world challenges.” The Stanford School of Design, (or “d.school” – which Kemble co-founded and currently directs) is already well-known for its open collaborative spaces, abundant supply of Post-It notes and markers, and improvisational brainstorm activities – almost the opposite of traditional lecture-based learning.

One “unexpected benefit” of dealing with real-world challenges is that we can change our approach as we go.  This is how it works in peer learning: peers can decide on different structures not just once (say, at the beginning of a course), but throughout the duration of their time together. This way, they are never “stuck” with existing structures, whether they be messy or clean. At least… that’s the ideal.

In practice, “bottlenecks” frequently arise.  For example, in a digital library context, there may be bottlenecks having to do with software development, organizational resources, community good will, or access to funding – and probably all of the above.  In a didactic context, it may be as simple as one person knowing something that others do not.

While we can’t eliminate scarcity in one stroke, we can design activities for peer learning that are “scarcity aware” and that help us move in the direction of adaptive learning structures.

Planning Peer Learning Activities

We begin with two simple questions:

  • How do we select an appropriate learning activity?
  • How do we go about creating a learning activity if we don’t find an existing one?

“Planning a learning activity” should mean planning an effective learning activity, and in particular that means something that people can and will engage with.  In short, an appropriate learning activity may be one that you already do!  At the very least, current activities can provide a “seed” for even more effective ones.

But when entering unfamiliar territory, it can be difficult to know where to begin.  And remember the bottlenecks mentioned above?  When you run into difficulty, ask yourself: why is this hard?  You might try adapting Zed Shaw’s task-management trick, and make a list of limiting factors, obstacles, etc., then cross off those which you can find a strategy to deal with (add an annotation as to why).  For example, you might decide to overcome your lack of knowledge in some area by hiring a tutor or expert consultant, or by putting in the hours learning things the hard way (Zed would particularly approve of this choice).  If you can’t find a strategy to deal with some issue, presumably you can table it, at least for a while.

Strategic thinking like this works well for one person. What about when you’re planning activities for someone else?  Here you have to be careful: remember, this is peer learning, not traditional “teaching” or “curriculum design”.  The first rule of thumb for peer learning is: don’t plan activities for others unless you plan to to take part as a fully engaged participant.  Otherwise, you might be more interested in the literature on collaborative learning, which has often been deployed to good effect within a standard pedagogical context (see e.g. Bruffee [1]).  In a peer learning setting, everyone will have something to say about  “what do you need to do” and “why is it hard,” and everyone is likely to be interested in everyone else’s answer as well as their own.

Furthermore, different participants will be doing different things, and these will be “hard” for different reasons. Part of your job is to try to make sure that not only are all of the relevant roles covered, but that the participants involved are getting enough support.

One scenario: building activities for the Peeragogy Handbook

Adding a bunch of activities to the handbook won’t solve all of our usability issues, but more activities would help.  We can think about each article or section from this perspective:

  1. When looking at this piece of text, what type of knowledge are we (and the reader) trying to gain?   Technical skills, or abstract skills?  What’s the point?

  2. What’s difficult here?  What might be difficult for someone else?

  3. What learning activity recipes or models might be appropriate? (See e.g. [2], [3].)

  4. What customizations do we need for this particular application?

** As a quick example: designing a learning activity for the current page

  1. /We want to be able to come up with effective learning activities to accompany a “how to” article for peer learners/

  2. /It might be difficult to “unplug” from all the reading and writing that we’re habituated to doing./

  3. But there are lots and lots of ways to learn.

  4. /Therefore, the proposed handbook activity is to simply step away from the handbook for a while./

  5. Look for some examples of peer learning in everyday life.  When you’ve gained an insight about peer learning from your own experience, come back and create a related activity to accompany another handbook page!

References

  1. Bruffee, Kenneth A. (1984). “Collaborative learning and the conversation of mankind.” College English 46.7, 635-652

  2. KS ToolKit from kstoolkit.org.

  3. Designing Effective and Innovative Sources (particularly the section on “Teaching Strategies for Actively Engaging Students in the Classroom”)

⚡ Unpeeragogy · Friction · Observation

Structure Adds Nothing

⏱ 4 minaudit-v2adding_structurebureaucracytrust

The Assumption

Structure should emerge from content and activity, not be imposed beforehand. Premature structure kills the organic creativity of peer groups. Decision-stagnation and authority-attrition are the primary failure mechanisms of imposed structure.

Operational Reality

The handbook presents the library example: a neighborhood learning space that should self-organize around genuine community needs. The claim is that structure must follow practice. What the example does not document is how many neighborhood spaces fail before they reach that point.

Books disappear. Meeting rooms are booked by the same three people. New members cannot find anything. Quiet study areas become social clubs that scare off older learners. Not because people are malicious — because useful friction requires intentional design that a self-organizing group has no mechanism to produce.

Perturbatore: “What if the structures we resist most are exactly the ones that would let us take bigger creative risks?”

Useful friction is not organic. It is designed.

P2PU shows that even successful peer learning benefits from intentional role design — defined facilitator roles and institutional partnerships create the minimum coordination that makes participation sustainable. OpenStreetMap shows that formal dispute resolution bodies resolve conflicts that informal consensus cannot. Drupal shows that structure must be designed, not awaited. The IETF shows that even the most peer-driven standards body needs formal fallback mechanisms.

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. Even successful peer learning benefits from intentional role design.
  • OpenStreetMap Data Working Group — Formal dispute resolution bodies with binding authority resolve peer production conflicts that informal consensus cannot. Structure enables resolution, not paralysis.

Fracture Cases (Complicating):

  • Drupal Governance — Governance transition from BDFL to community model required years of structural work. The assumption that structure follows content is contradicted by Drupal: structure must be designed, not awaited.
  • IETF About — Rough consensus governance only works when backed by hierarchical escalation paths. Even the most peer-driven standards body needs formal fallback mechanisms.

Operational Heuristics

Positive Boundary: Apply this pattern only when the group’s primary purpose is exploration and relationship-building — and even then, define minimal roles to sustain coordination.

Negative Boundary: Do not apply this pattern when the group has defined deliverables or when conflicts require resolution — formal dispute resolution with binding authority resolves conflicts that informal consensus cannot handle.

Epistemic Synthesis

The central assumption — that structure must follow content — is contradicted by the evidence. Every successful peer production case in the archive required intentional structural design. Structure does not kill creativity — it kills the excuse for not delivering. The theoretical pattern is useful only if read backwards: not “structure after content” but “minimum structure as prerequisite for content.”

Evidence Status

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

Traceability

Run: audit-v2 · Delta: 1.4 → 1.44 · Diversity D: 2

References

💬 Field Report: Structure Adds Nothing

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.