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

Resources

Creating a guide

⏱ 3 min

Context

Meaning-carrying tools, like handbooks or maps, can help collect content and stories as well as assist others who want to adopt the idea.

Problem

Established ideas have knowledge cartography challenges for newcomers, consider trying to decipher a subway map in a foreign city. When the idea or system is only “newly discovered”, the associated meanings may not be well understood, and indeed they may not have been created. Even if a topic is only “personally new”, it can be hard to find one’s way around.

Solution

The process of creating the guide can go hand-in-hand with figuring out how the system works. Thus, techniques of knowledge cartography and meaning making are useful for would-be guide creators.[fn:1]

Rationale

It is important to keep in mind how “the map is not the territory,” and map-making is only one facet of shared human activity. For instance, a pattern description can be thought of as a “micro-map” of a specific activity. These maps are not useful if they are divorced from practice. The process of creating a guide creates a certain formality to the project, forcing participants to catalogue and explicate their idea. Additionally, the act generally leads to deadlines which can help prod individuals to work on the project more regularly.

Resolution

Writing down this pattern clarifies the importance of creating a guide for your idea if you want others to adopt it for use.[fn:2] If people complain that they are confused, now we know why.

What’s Next

Working with our shepherd at PLoP to improve this paper![fn:3]

dashboard (image by Amanda Lyons, used with permission).

[fn:1] We started the Peeragogy project by collaboratively making an outline for the Peeragogy Handbook. We recommended this handbook-making practice to others, as a way to learn collaboratively and build a strong group.

[fn:2] As Richard Stallman wrote about free software documentation: “The biggest deficiency in free operating systems is not in the software—it is the lack of good free manuals that we can include in these systems. Many of our most important programs do not come with full manuals. Documentation is an essential part of any software package; when an important free software package does not come with a free manual, that is a major gap.”

[fn:3] Regarding connections with programming per se: we are not currently making software in the Peeragogy project, but we do continually evaluate and assemble software tools to support our activities. We often run into “bottleneck” problems; see Carrying capacity. The better we are able to exposit the problems we’re dealing with, the more likely it is that our high-level analysis (and synthesis) has the potential to inform future programming work.

⚡ Unpeeragogy · Friction · Observation

The Guide Is a Labyrinth

⏱ 4 minaudit-v2creating_a_guidemapdocumentation

The Assumption

Creating guides is a collaborative process where experienced members share knowledge with newcomers, fostering inclusive participation through accessible documentation. Comprehensive guides reduce barriers to entry — more documentation means more access.

Operational Reality

Nothing says “go away” like a 47-page onboarding guide written by people who forgot what it is like to not know anything. This pattern repeats across makerspaces, open source projects, and community initiatives. The founders create elaborate documentation — flowcharts, decision trees, comprehensive FAQs — believing they are helping newcomers navigate complexity. The opposite occurs. Each additional page becomes another barrier, another signal that this space was not built for someone like you.

Not unclear writing. Not missing information. Not poor organization. The guide itself becomes the gatekeeper — a labyrinth that sorts the dedicated from the merely curious. The people who built it can no longer see what they have made because they know all the shortcuts.

Wikidata demonstrates that complex governance processes in peer production projects create participation barriers that entrench existing contributors and exclude newcomers. Drupal shows that even well-documented projects create invisible barriers through the sheer complexity of their governance processes.

instead of welcoming newcomers?“*

Empirical Evidence

Resilience Cases (Confirming):

  • None in the current corpus. This is a gap: no documented cases of guides successfully reducing barriers exist in the audit archive.

Fracture Cases (Complicating):

  • Wikidata Governance — Complex governance processes in peer production projects create participation barriers that entrench existing contributors and exclude newcomers. Comprehensive documentation does not welcome — it sorts.
  • Drupal Governance — Intentional governance transition from BDFL to community model required years of structural work, not organic emergence. Even well-documented projects create invisible barriers through the sheer complexity of their governance processes.

Operational Heuristics

Positive Boundary: Guides function when tested with actual newcomers and revised based on their feedback — guide complexity should be inversely proportional to available human support.

Negative Boundary: Do not assume comprehensive guides increase participation — complex governance documentation creates barriers that consolidate existing contributors and exclude newcomers, transforming the guide from bridge to wall.

Epistemic Synthesis

The highest tension delta in the corpus. Wikidata and Drupal show that comprehensive guides create the opposite of their intended effect — they become walls instead of bridges. Complex governance processes do not document complexity: they manufacture it, transforming participation into a credential newcomers must earn instead of a space they can simply enter. The question is not how to make the perfect map, but whether the territory itself must remain partially unmapped.

Perturbatore: “What if the best guides are the ones that admit they cannot guide you — and complex governance processes manufacture participation barriers that entrench existing contributors instead of welcoming newcomers?”

The map grows. The newcomers stop coming.

Evidence Status

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

Traceability

Run: audit-v2 · Delta: 1.3 → 1.72 (±0.42) · Diversity D: 2

References

💬 Field Report: The Guide Is a Labyrinth

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.