Subject: [NYCGA-IWG] Re: [Occupy-dev] Social voting vs. administrative decision
From: David Stodolsky
Date: Wed, 16 Nov 2011 11:56:04 +0100
To: Michael Allan
CC: Occupy Dev <>, Internet Working Group <>, OWS Solutions <>

On 16 Nov 2011, at 10:55 AM, Michael Allan wrote:

Dear Beth, David and Planetary,

Progress here appears to require more clarification of the concepts, particularly 'decision' and 'vote.'

It might help to look at voting and decision as logically distinct
processes.  Technically speaking, signals of agreement or disagreement
in the GA are votes.  

People showing approval of a speaker are not normally considered to be voting, nor are those that are blocking. 

The fact that you can total agreement/disagreement signals does mean that simple vote counting techniques can play  a role. However, calling every process that counts up signals 'voting' can confuse the issue.

The GA also incorporates a mechanism to detect
consensus and to promulgate decisions.  So it combines both voting and
decision processes in a single system.  Not *all* decision processes
require voting, but all that are based on agreement do.

With ConsensusVoIP, acceptance of a statement requires universal agreement, but this doesn't require voting. That is, any statement can be 'blocked' and the blocks have to be heard and processed to reach agreement about the statement. 

So, the key distinction is between inputs that guide the process vs. inputs that finalize a substantive decision. The key feature of consensus decision making is that we try to reach agreement without voting. This conforms to common usage (from my dictionary):

Decision: a conclusion or resolution reached after consideration

Vote: a formal indication of a choice between two or more candidates or courses of action, expressed typically through a ballot or a show of hands or by voice. 

My claim is that direct deliberation among all participants can scale up to cover whatever jurisdictional size is required. Further, I argue that it is theoretically tractable and therefore more resistant to manipulation or unpredictable behavior than ad-hoc multi-level/locus solutions. 


By the same token, not all voting systems are necessarily tied to a
decision mechanism.  An opinion poll is an example of a voting system
that's not directly connected to any decision mechanism.  It just
collects and reports the votes.  Another example is the voting system
we work with in my own project.  It may be of interest here, because
it was designed to support large scale discussion, consensus and
mutual understanding.  Here's a snapshot of the structure:

                      (0)  (0)  (0)
                        \ 1 | 1 /
                         \  |  / 1    (0)   (0)
                (0)  (0)  \ | /        | 1  /
       (0)        \ 1 |    \|/         |   / 1
         \ 1       \  | 1  (3)         |  /
          \         \ |     |          | /  (0)  (0)
           \         \|     | 4        |/    | 1 /
        1   \        (2)    |         (2)    |  / 1
    (0)-----(2)        \ 3  |          |     | /
              \ 3       \   |          | 3   |/
               \         \  |          |    (3)-----(0)
                \         \ |    (0)   |    /     1
     1       2   \         \|      \ 1 |   /
 (0)-----(1)-----(5)       (7)      \  |  / 4
                   \ 6     /         \ | /
                    \     / 8         \|/
                     \   /            (8)
                      \ /

 Each line is a vote by one person (voter) for another (candidate).
 Votes are transitive, so the result is a tree structure.  The trees
 are actually be much bushier in reality, with roughly 5-20 branches
 per candidate node. A fancier version of this diagram is shown on
 our home page:

Crucially each candidate node defines a relatively small discussion
cell (up to 21 members) that overlaps slightly with its uptree and
downtree neighbours.  The topic of discussion is how to reach
consensus, and why it hasn't happened yet.

Consensus itself isn't the only goal.  It may be difficult to achieve
consensus, or it may even be impossible.  Failing consensus, the most
important thing is for people to acknowledge the failure (the fact of
dissensus) and to understand the reasons for it.  As a rule, decision
mechanisms have nothing positive to contribute to this understanding,
and should therefore be kept at a safe distance from the basic voting
system.  I think the design of the GA is unfortunately flawed in this
regard.  If the main purpose is to support "community and social
interaction, expansion and consideration" as Beth implies, then it
should be structured purely by voting.

Or, if the main purpose is to support decision making (as in most
assemblies), then we should be looking elsewhere for the community we
are trying to help.  This in turn might fit with the "step back" that
Planetary calls for.  The goal of consensus is "finding a solution
everyone can live with", so the first step is to include everyone in
the discussion.

Michael Allan

Toronto, +1 416-699-9528

Beth wrote:
The purpose of consensus decision-making is not about voting.  In
fact, it is the opposite of voting: it is about finding a solution
everyone can live with, not that the most people most passionately
support.  It is about community and social interaction, expansion and
consideration.  It is harder than voting, yes, it is slower, but the
result is democratic in a way that representative decisions, chosen by
a vote, can never be.

The infrastructure here could support that, especially if it supports
non-digital votes (so people could dial support) and comments (so we
can do root problem analysis on opposition), but expecting this to
take the place of consensus is a great way to go back to
business-as-usual and tyranny-of-the-majority.


planetary wrote:
Co-signed.   We should be trying to answer the question:

"How do we apply human-driven facilitation in order to achieve Consensus over wider areas, in order to achieve larger joint projects across local contexts?"

Instead,  the proposals seem to be getting at:

"How do we build A System that produces a 'vote result' as efficiently as possible for the largest possible (trusted) audience?"

The desire for the former outcome was the foundation of our Superassembly concept for a synchronous multi-GA consensus session method:

We're aware this proposal was a bit complex, but if you think of it in terms of these benefits/applications, maybe you'll find something you can use here:

- This is a way of doing a big synchronous Consensus session, not necessarily a E2E process 
- This can fit into async processes (like the InterOcc approach) as a final voting stage, be used for special referenda only, etc.
- It's not necessarily a daily, weekly, or even regular event.  It really should be applied for special Inter-GA business and coordination, which we expect would take a great deal of preparation from focused working groups anyway, so offline review period, consensus-building, would be presumed to have been done. 
- This is a way of combating complexity by preserving the same small number of queues (stacks) and interfaces (participants -> facilitators / stackers -> floor -> group), interrupts (block signals), etc
- The process is already familiar to all  - you just get on a stack & listen to the PPBX like usual, so adoption would be significantly easier. 
- This could be done really, really cheap and almost completely independently, unlike big full duplexes or massive central servers. 

Hope that helps. We appreciate everyone's desire for efficacy but whenever we find ourselves wishing to remove or substitute human political activity -  facilitation is not simple automatable labor - we should pause and consider whether the efficiency trade-off is still within an acceptable human threshold. 

Also: please note new e-mail address for those previously in receipt of our stuff.

Yours in solidarity,


David Stodolsky wrote:

On 15 Nov 2011, at 8:23 PM, planetary wrote:

Co-signed.   We should be trying to answer the question:

"How do we apply human-driven facilitation in order to achieve Consensus over wider areas, in order to achieve larger joint projects across local contexts?"

This *is* what my ConsensusVoIP proposal suggests. It is not a voting system of any kind. The inputs manage a dialog process. 

. . .

planetary wrote:
This thread implicitly raises an important series of questions for us technologists & planners. 

Most important being, given the state of the flagship encampment, & the coordinated national move to end the encampments: 

(1) Is inter-site coordination/Consensus the most important thing for this skilled group of people to focus  their efforts on given this week's developments? 

(2) Are our assumptions about the physical context and operating model invalid, if the encampment model & available Consensus processes are materially altered by new conditions?

(3)  Does it matter, given how much rebuilding there is to do in the 'flagship' site - and how much we collectively could be contributing to that, when not trying to solve this?

We are starting to feel that we should reassess the needs and priority of Inter-Occ programs - at least ones that rely on assumptions about camp configurations - when encampment strategy & tactics are settled, especially if the wave of evictions in the major influential / lynchpin sites is still in progress. (We suspect it is, & major cities are likely operating on a Thanksgiving timetable.) 

We just wonder - if this is cycle will continue to repeat, do we need to step back & apply ourselves to Camp Preservation and alternative Direct Action type contributions? e.g. figure out ways to more effectively limit the damage of eviction events through cheaper / more portable components, focus more on 'flash mobbing' and mobile actions, ?
Occupy-dev mailing list

David Stodolsky                  Blog:          Skype/Twitter: davidstodolsky