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

Peeragogy in Practice

Polling for ideas

⏱ 2 min

Definition:

Polling for Ideas can happen at many junctures in a peer learning experience. We could poll for ideas like “what’s missing?”, “who might like to join our group?”, and “what are the right tools and resources for us to use at this point?”

Problem:

We recognize that we don’t always know the answers in advance – particularly if we’re trying to come up with an answer that satisfies other people.

Solution:

Others might have an important or useful idea. Even if all you can supply is the question and a context for discussion, they may be willing to contribute these answers.

Example:

Near the start of the project, Howard suggested that we use the forum categories he set up, but opened the floor to other ideas, in this way: “At the beginning, until we all know the ropes well enough to understand when to create a new discussion forum topic and when to add to an existing one, let’s talk in this topic thread about what else we want to discuss and I will start new topic threads when necessary.”

Challenges:

In the Peeragogy in Action Google+ community, and in our earlier Social Media Classroom forum, both of which have been open to any suggestion at all, we’ve many different ideas appear and then roll by without being catalogued. When you have too much data, it can be necessary to take separate steps to organize it. At the other end of the spectrum, people don’t always respond to surveys, and you can end up with less data than you’d like.

What’s Next:

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”.

⚡ Unpeeragogy · Friction · Observation

Polling for Ideas Is a Status Check

⏱ 4 minaudit-v2pollingideasdecision

The Assumption

Polling for ideas leads to decision-stagnation, distributes responsibility to avoid accountability, and real direction emerges from champions rather than polls.

Operational Reality

A community garden project spent three months polling members about what to plant. Google Forms, ranked choice, discussion threads — every participatory tool available. The results were clear: tomatoes, basil, zucchini. Nobody planted anything. The poll had distributed responsibility so evenly that no one felt authorized to buy seeds.

Then one member showed up with tomato starts and planted them without asking. The garden produced tomatoes that season.

The pattern correctly diagnoses the problem: polling without authority produces paralysis. But it misses the counter-case. OpenStreetMap’s Data Working Group uses formal voting with binding authority. Wikipedia’s Good Article process uses structured peer review with published criteria. These are not polls — they are decision systems with consequences. The difference is not the mechanism. It is whether someone enforces the result.

Empirical Evidence

Resilience Cases (Confirming):

  • OpenStreetMap Data Working Group — Formal dispute resolution bodies with binding authority and published reasoning resolve peer production conflicts. Polling with binding authority produces accountable decisions.
  • Wikipedia Good Article Process — Peer assessment with transparent criteria and independent reviewers creates sustainable quality tiers. Structured peer review with enforcement mechanisms produces better outcomes than informal champion emergence.

Fracture Cases (Complicating):

  • WebAssembly Community Group — Choosing lighter governance models for standards development trades authority for speed, creating different failure modes. Polling without binding mechanisms produces the exact paralysis the pattern diagnoses.
  • MakerDAO Black Thursday — DAO governance mechanisms designed for normal operations can fail catastrophically under stress. Polling without emergency override produces systemic failure.

Operational Heuristics

Positive Boundary: Polling works when combined with binding authority and transparent criteria — structured peer review with enforcement mechanisms produces better outcomes than informal champion emergence.

Negative Boundary: Do not apply this pattern when formal governance structures with binding authority already exist — the problem is not polling itself, but the absence of enforcement.

Epistemic Synthesis

The pattern correctly identifies the problem: polling without authority produces paralysis. But the counter-case is instructive. OpenStreetMap votes with binding authority. Wikipedia evaluates with published criteria. The difference is not the mechanism — it is whether someone enforces the result. A poll without consequences is a thermometer, not a steering wheel.

Perturbatore: “What if sometimes the crowd actually knows what it wants — it just needs someone to count the votes and enforce the result?”

A poll without consequences is a thermometer. Not a steering wheel.

Evidence Status

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

Traceability

Run: audit-v2 · Delta: 1.3 → 1.1138 (±0.1862) · Diversity D: 2

References

💬 Field Report: Polling for Ideas Is a Status Check

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.