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

Cooperation

Participation

⏱ 4 min

Methods of managing projects, including learning projects, range from more formal and structured to casual and unstructured. As a facilitator, you’ll see your peeragogy community constantly adjust, as it seeks an equilibrium between order and chaos, ideally allowing everyone to be involved at their own pace without losing focus, and in such a manner that the collective can deliver.

For teachers reading this, and wondering how to use peeragogy to improve participation in their classrooms, it’s really quite simple: reframe the educational vision using peeragogical eyes. Recast the classroom as a community of people who learn together, the teacher as facilitator, and the curriculum as a starting point that can be used to organize and trigger community engagement. However, just because it’s simple doesn’t mean it’s easy! Whatever your day job may be, consider: how well do the various groups you participate in work together – even when the members ostensibly share a common purpose? Sometimes things tick along nicely, and, presumably, sometimes it’s excruciating. What’s your role in all of this? How do you participate?

Guidelines for participation

  • Accept that some people want to watch what is going on before jumping in. This doesn’t mean you have to keep them hanging around forever. After a while, you may un-enroll people who don’t add any value to the community. In our Peeragogy project, we’ve asked people to explicitly re-enroll several times. Most do renew; some leave.
  • Accept that people may only contribute a little: if this contribution is good it will add value to the whole.
  • Understand that you can not impose strict deadlines on volunteers; adjust targets accordingly.
  • Let your work be “open” in the sense described in Wikipedia’s Neutral Point of View policy.
  • Give roles to participants and define some “energy centers” who will take the lead on specific items in the project.
  • Organize regular face-to-face or online meetings to talk about progress and what’s needed in upcoming days/weeks.
  • Ask participants to be clear about when they will be ready to deliver their contributions.
  • Have clear deadlines, but allow contributions that come in after the deadline – in general, be flexible.
  • Add a newcomer section on your online platform to help new arrivals get started. Seasoned participants are often eager to serve as mentors.

When we think about project management in an organization, we often relate to well-established tools and processes. For example, we can use the Project Management Body of Knowledge (PMBOK) as a standard. For the Project Management Institute (PMI) and many workers, these standards are seen as the key to project success. In classical project management, tasks and deadlines are clearly defined. We will, for example, use Program Evaluation and Review Technic (PERT) to analyze and represent tasks. We often represent the project schedule using a Gantt chart. Those are just two of the project management tools that illustrate how “mainstream” project management rests firmly on an engineering background. In these very structured projects, each actor is expected to work exactly as planned and to deliver his part of the work on time; every individual delay can potentially lead to a collective delay.

Peeragogy projects may be, naturally, a bit different from other settings, although we can potentially reuse both formal and informal methods of organization. For example, unlike a typical wiki – or classroom – peeragogy projects often expect to break the 90/9/1 rule. Keep in mind that some participants may not contribute all the time – but one really good idea can be a major contribution. See the anti-pattern “Misunderstanding Power” for some further reflections on these matters.

How are we doing? If we consider our basic population to be those in our Google+ community, then as of January 2014, over 4% have contributed to the handbook – pretty good. However, we have yet to reach a contribution profile like 702010. It’s important to remember that – especially in a volunteer organization – no one can “make”’ other people participate, and that all the lists of things to do are for nought if no one steps in to do the work. For this reason, if anything is going to happen, what’s needed are realistic estimates of available work effort. Finally, in closing this section, we want to emphasize that measures of participation offer only a very rough proxy for measures of learning, although the two are clearly related.

⚡ Unpeeragogy · Friction · Observation

Participation Isn't Automatic

⏱ 4 minaudit-v2participationinequalityconsensus

Perturbatore: “What if democracy is two wolves and a sheep voting on dinner — and peeragogy is three wolves who showed up to every meeting deciding what counts as consensus?”

The Assumption

Most members in a peer group do not participate, only a few do. Participation is often seen as a cost rather than a benefit, and lack of recognition leads to decreased participation.

Operational Reality

Three wolves and a sheep vote on dinner. Democracy in action. Peeragogy replaces the three wolves with the people who show up to every meeting, the sheep with the people who could not make the call because they had childcare. The vote is unanimous. Everyone consented. The people who did not vote now eat what the regulars decided.

Not manipulation. Not bad faith. Just the physics of participation inequality.

OpenStreetMap’s Data Working Group exists precisely because informal consensus failed to resolve data disputes. The people who showed up consistently had disproportionate influence, and the people who did not show up lost trust in the process. Formal dispute resolution with binding authority did not reduce participation — it protected the legitimacy of decisions by making authority explicit.

Participation inequality is not a bug. It is a feature of any system where attendance is voluntary and stakes are unequal. The question is not how to fix it, but how to govern its consequences. WebAssembly shows that participation inequality persists regardless of governance weight — lighter models just make it harder to challenge. Wikipedia’s deletion debates show that participation creates authority and transparent consensus legitimation reifies existing hierarchies.

Empirical Evidence

Resilience Cases (Confirming):

  • OpenStreetMap Data Working Group — Formal dispute resolution bodies with binding authority and published reasoning resolve peer production conflicts that informal consensus cannot. Explicit authority structures protect legitimacy when participation is unequal.

Fracture Cases (Complicating):

  • WebAssembly Community Group — Choosing lighter governance models for standards development trades authority for speed, creating different failure modes. Participation inequality persists regardless of governance weight — lighter models just make it harder to challenge.
  • Wikipedia Deletion Debates — Consensus processes produce de facto hierarchies through participation inequality — those who show up consistently gain disproportionate influence. Participation creates authority and transparent consensus legitimation reifies existing hierarchies.

Operational Heuristics

Positive Boundary: This pattern works when governance structures are designed explicitly to manage participation inequality — participation creates authority; governance design either manages it explicitly or suffers it as default.

Negative Boundary: Do not assume informal consensus can handle all conflicts in groups with unequal participation — formal dispute resolution exists precisely because informal consensus failed to resolve disputes that required binding decisions with published reasoning.

Epistemic Synthesis

Participation inequality is not a bug. It is a feature of any system where attendance is voluntary and stakes are unequal. OpenStreetMap created a Data Working Group not to increase participation but to protect the legitimacy of decisions in the face of structurally unequal participation. The tension is not between inclusion and efficiency, but between those who participate and those who hold authority.

Perturbatore: “What if democracy is two wolves and a sheep voting on dinner — and peeragogy is three wolves who showed up to every meeting deciding what counts as consensus?”

Voting on dinner is not democracy. It is logistics with a body count.

Evidence Status

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

Traceability

Run: audit-v2 · Delta: 1.6 → 1.7492 (±0.1492) · Diversity D: 2

References

💬 Field Report: Participation Isn't Automatic

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.