[Home]ConsensusPolling

MeatballWiki | RecentChanges | Random Page | Indices | Categories
ConsensusPolling is about winning together or refusing to play the game. It is only really appropriate when a group of individuals must collectively solve a problem that affects them all. It seeks to avoid voting for candidate options (see VotingIsEvil) when such a vote would generate winners and losers and thus divide the community that must support the result of the collective decision.

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:

This document is created BEFORE the poll begins and describes exactly what levels of participation, commitment of resources, and consensus of those involved must be achieved in order for the "action plan" to become binding (also specifies any other preset conditions such as a cloture threshold that might be needed for larger scale polls). The only way to change the static "contract" is for the owner of the poll to cancel it and start an entirely new poll. This guarantees that the meaning of pledges and yes/no votes never change: "I agree, but OnlyIf the minimums in the static contract are exceeded."

Often the language in a consensus poll will include a statement such as "This poll cannot make a negative statement. The results of this poll become meaningful OnlyIf the minimums in the static contract are met. Failure to reach the minimums should not be construed as making a statement of any kind."

2. Dynamic ActionPlan?:

The group of poll participants/pledgers works on the ActionPlan? together until it satisfies enough pledgers to pass the "go" thresholds that were laid out in the Static Contract.

3. Yes/No Poll:

A "temperature" reading that allows everyone to see who is voting no and who is voting yes, and to track progress toward the "go" thresholds. Any participant can change their vote from yes to no or from no to yes at any time.

4. Public Forum:

A place for members voting no to explain their concerns, and for members voting yes to listen to and address the concerns of those who are voting no

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

Rapid consensus

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.

e.g.

Current action plan: Do blah, feed the fish, eat the fish, undo blah. (17:35 Monday 17th).

Name Vote Timestamp
Chris Yes 18:45 Monday 17th
Bill Yes 17:35 Monday 17th
Bob Yes 19:02 Monday 17th

Fresh votes: 100% — Plan approved

-- ChrisPurcell

I love this way to achieve fast consensus! -- TedErnst

ConsensusPolling a ConsensusGroup

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.

New name?

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

BeyondYes is the name of a company started by BrandonCsSanders and TedErnst to bring these ideas into the world. We're not satisfied yet with any of the names for the "meta" of these ideas. Consensus isn't quite right because of how loaded the word is (is taken to mean 100% in many circles). Polling certainly isn't right, as people can change their status at any time. --TedErnst

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

DynamicApproval?? -- TedErnst

I prefer ProgressiveApproval?, it's got a nice ring of actually achieving something over time ;) -- ChrisPurcell

I like it. Let's move this page there! -- TedErnst

CategoryConflict CategoryConsensus CategoryOnlyIf

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: