Rather than a menu of candidates to choose from, the entire process is controlled by an evolving Yes/No vote. The vote reflects the suitability of a single community-owned solution being generated through a process of collaborative CollectiveIntelligence. All participants are free to change their vote at any time. A yes vote says "I believe the current articulation of our solution is good enough," a no vote says "I have concerns that haven't been adequately addressed by the current solution." Only when the Yes votes pass some very high, pre-specified threshold (e.g., 95%) can the solution proposed be considered to reflect the consensus of the community.
ConsensusPolling consists of four parts:
1. Static OnlyIf Contract:
2. Dynamic ActionPlan?:
3. Yes/No Poll:
4. Public Forum:
I've seen this work to end a 3 month deadlock on a contentious issue on OmidyarDotNet. In four days we achieved near-unanimous (92.4% - 61 yes, 5 no) consensus on a group owned plan. --BrandonCsSanders
This is similar to FundableDotOrg and PledgeBank. One key difference being that with ConsensusPolling the "pledged action" can evolve via CollectiveIntelligence whereas with the other two it is pre-specified and cannot change.
I think this is also similar to BarnRaising.
This kind of unanimous (or near-unanimous) consensus is also found in ConsensusGroup, and mulled over in VetoTopic.
TedErnst (also on MeatBall) is one of the key people behind the successful consensus poll that helped unstick a sticky process at OmidyarDotNet.
It seems like ConsensusPolling could be an important tool for http://joi.ito.com/joiwiki/EmergentDemocracyPaper
One weakness of this algorithm as specified is, I feel, that as designed it cannot safely reach a rapid conclusion, even if there is unanimous consensus amongst the group members, without an out-of-line approach.
It's not stated here, but for the ConsensusPolling mechanism to converge stably, the static contract demands a term equivalent to "the action plan can become binding only if it remains unchanged for a minimum period of time". To see why, imagine 90% of the community say "yes" to a version of the action plan. At this point, the remaining 10% can subvert the whole process by making significant changes to the action plan then changing their votes. Unless the remaining 90% are on the ball, the changed plan is approved despite 90% never having agreed to it.
It must thus be part of the static contract that there is a minimum time in which to veto your own yes vote if the dynamic contract changes significantly. However, that means the group cannot take action more rapidly than this minimum time, even if complete consensus is achieved.
Fixing this problem is simple: extend the mechanism to allow a specific version of the dynamic plan to be mooted as final, with an immediate vote taken on just that revision, a static vote if you will. (Obviously, this should only be done if the dynamic Yes votes reach the minimum threshold.) If the immediate vote gains the required number of approvals, the minimum peer review time can be skipped.
Other codifications of the same strategy are possible, allowing the community to impart more information more quickly into the consensus process. Every revision of the dynamic action plan, and every Yes vote, should be given a timestamp. If the dynamic action plan is changed, users can approve the changes explicitly (rather than the SilentAgreement of the original scheme) by touching their Yes votes' timestamps. If at any time the number of Yes votes made more recently than the current action plan (fresh votes) exceeds, say, 95%, the scheme is accepted right then.
Current action plan: Do blah, feed the fish, eat the fish, undo blah. (17:35 Monday 17th).
|Chris||Yes||18:45 Monday 17th|
|Bill||Yes||17:35 Monday 17th|
|Bob||Yes||19:02 Monday 17th|
Fresh votes: 100% — Plan approved
As a quick note, one can happily do consensus polling of a consensus group; the two ideas are orthogonal. This can allow rapid progress to be made on a long-term project even if the team slowly changes over time.
Is "consensus polling" the best name for this idea? There seems to be no congruence with any of the definitions on WikiPedia:Polling. "BeyondYes" is unfathomable at first glance. How about ConsensusPlanning?? -- ChrisPurcell
Some relevant words to choose from: building, rolling, progressive, dynamic, majority, supermajority, quorum, commitment, planning, deliberation, negotiation, approval, debate. Something like ApprovalBuilding? or DeliberatePlanning?, for example, is nicely PR-ish, without actually meaning anything ;) -- ChrisPurcell
I prefer ProgressiveApproval?, it's got a nice ring of actually achieving something over time ;) -- ChrisPurcell