Subject: Consensus by direct action (was: Re: [Occupy-dev] [Ows_solutions] [NYCGA-IWG] Re: Project Proposal: Occupy Wall St The App (iOS/Android)
From: David Stodolsky
Date: Tue, 15 Nov 2011 21:00:47 +0100
To: occupy-dev@lists.takethesquare.net, Internet Working Group <internet_working_group@googlegroups.com>, ows_solutions <ows_solutions@freenetworkfoundation.org>
CC: Beth <sylvanstargazer@gmail.com>, planetary <planetary@plntry.net>, Matthew Lepacek <pursuitofliberty@gmail.com>


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. 



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:  http://plntry.net/adv/adv_001.htm

From my reading, this is more of a voting system than my ConsensusVoIP proposal. While this Superassembly approach has votes interspersed with deliberation, my ConsensusVoIP proposal has only deliberation.



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 

E2E is what?


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

There is no substitution of human political activity with ConsensusVoIP. The automated activities are mechanical processes, like adding up how long someone has spoken. The objective is to equalize the political influence of all participants, which we will not have if certain persons have the privileged position of moderating/facilitating. 




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

Yours in solidarity,

@planetary_io
planetary@plntry.net
http://www.plntry.net


On Nov 15, 11, at 10:57 AM, 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)

This is an option.


and comments (so we
can do root problem analysis on opposition)

With the Consensus Journal procedure, comments are invited from all identified subgroups.



dss


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

-Beth

On Tue, Nov 15, 2011 at 1:42 PM, David Stodolsky <dss@secureid.net> wrote:

On 15 Nov 2011, at 6:58 PM, Scot Summers wrote:

The facilitators will undermine any and all attempts at their point of
leverage. It's like the most academic snobby secret game of king of the hill
evar.

That is a good argument for employing this approach.
The only leverage facilitators have with this type of setup is not using it.
That assumes good security, open source, etc.
If we have a server free implementation, then even that option is gone. It
is quite straight forward to set this up as peer-to-peer, but then security
has to be built in from the start - to avoid cheating.

dss

Sent from my iPod
On Nov 15, 2011, at 6:50 AM, David Stodolsky <dss@secureid.net> wrote:


On 13 Nov 2011, at 10:53 AM, Matthew Lepacek wrote:

 We can't seek to change anything about the GA as it is today in our
process, we can only compliment it 1:1 for what it is today, and ensure it
is adaptable as the GA evolves process over time.

I would apply the 1:1 to the principles of the GA, not the specific
techniques, since they are technology dependent.
The main complaints about GAs are that they are too slow to make decisions
and are often are controlled by a small group. New technology can help
overcome these criticisms. We have social science results and these should
be used whenever possible to increase the horizontality of the process.

The idea of multiple choice voting options has evolved now into how we can
handle ad-hoc dynamic temperature checks which can happen at any given
moment.

This presents info to a coordination/moderation team, who hopefully makes
fair decisions. Here is an example of how the GA can directly manage the
process:

In Boulder they are working on using Twitter as a back channel for

evaluating the current speaker - over VoIP. This was my suggestion, but

without the reputation element:

A primitive version of ConsensusVoIP (CV) would support the following

tweets:


Support2-Addition or correction offered

Support1-Additional information needed

Support0-Sounds good

Oppose3-Do not understand

Oppose2-Not sincere, Joke, etc.

Oppose1-False

Oppose0-Waste of time


As a speaker finishes, the total of  "Support" vs. "Oppose" tweets is

computed. If there are more Oppose tweets, then the highest priority

oppose, Oppose3, is selected for processing (Oppose0 is not a block and

therefore not a request to speak?). Of those who have tweeted Oppose3, a

person is randomly selected as the next speaker. CV would then speak the

name and priority/objective. For example, Bob-Oppose1 yields "Bob sees an

error" as an introduction from CV.

It will probably be necessary to use a server for the VoIP, so the back

channel could go back to it. This could be a lot more secure then tweeting.


Another approach would be switch modes once Support tweets reached

2/3rds. Then Oppose inputs would be given the highest priority to see if

all blocks could be eliminated.


I describe how effective time management could be added to this type of
protocol:
Stodolsky, D. (1984, December). Self-management of criticism in dialog:
Dynamic regulation through automatic mediation. Paper presented at the
symposium Communicating and Contracts between people in the Computerized
Society, Gothenburg University, Sweden.

http://dss.secureid.org/stories/storyReader$90



This model issues invitations to respond based upon peoples' reputations.
Extended abstract (5 min. read):

Stodolsky, D. S. (2002). Computer-network based democracy: Scientific
communication as a basis for governance. Proceedings of the 3rd
International Workshop on Knowledge Management in e-Government, 7, 127-137.

http://dss.secureid.org/stories/storyReader$14


Comprehensive

Stodolsky, D. S. (1995). Consensus Journals: Invitational journals based
upon peer review. The Information Society, 11(4).

http://dss.secureid.org/stories/storyReader$19



dss
David Stodolsky, PhD                   Institute for Social Informatics
Tornskadestien 2, st. th., DK-2400 Copenhagen NV, Denmark
dss@socialinformatics.org          Skype/Twitter: davidstodolsky
Blog: http://cosmism.blogspot.com


_______________________________________________
Ows_solutions mailing list
Ows_solutions@freenetworkfoundation.org
http://freenetworkfoundation.org/mailman/listinfo/ows_solutions_freenetworkfoundation.org

David Stodolsky                  Blog: http://cosmism.blogspot.com
dss@socialinformatics.org          Skype/Twitter: davidstodolsky




_______________________________________________
Occupy-dev mailing list
Occupy-dev@lists.takethesquare.net
https://lists.takethesquare.net/mailman/listinfo/occupy-dev


_______________________________________________
Occupy-dev mailing list
Occupy-dev@lists.takethesquare.net
https://lists.takethesquare.net/mailman/listinfo/occupy-dev

_______________________________________________
Occupy-dev mailing list
Occupy-dev@lists.takethesquare.net
https://lists.takethesquare.net/mailman/listinfo/occupy-dev

David Stodolsky                  Blog: http://cosmism.blogspot.com
dss@socialinformatics.org          Skype/Twitter: davidstodolsky



< PREV INDEX SEARCH NEXT >