|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: firstname.lastname@example.org, Internet Working Group <email@example.com>, ows_solutions <firstname.lastname@example.org>|
|CC: Beth <email@example.com>, planetary <firstname.lastname@example.org>, Matthew Lepacek <email@example.com>|
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: http://plntry.net/adv/adv_001.htm
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,@planetary_ioOn 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)
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.
On Tue, Nov 15, 2011 at 1:42 PM, David Stodolsky <firstname.lastname@example.org> wrote:On 15 Nov 2011, at 6:58 PM, Scot Summers wrote:The facilitators will undermine any and all attempts at their point ofleverage. It's like the most academic snobby secret game of king of the hillevar.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. Itis quite straight forward to set this up as peer-to-peer, but then securityhas to be built in from the start - to avoid cheating.dssSent from my iPodOn Nov 15, 2011, at 6:50 AM, David Stodolsky <email@example.com> 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 ourprocess, we can only compliment it 1:1 for what it is today, and ensure itis adaptable as the GA evolves process over time.I would apply the 1:1 to the principles of the GA, not the specifictechniques, since they are technology dependent.The main complaints about GAs are that they are too slow to make decisionsand are often are controlled by a small group. New technology can helpovercome these criticisms. We have social science results and these shouldbe used whenever possible to increase the horizontality of the process.The idea of multiple choice voting options has evolved now into how we canhandle ad-hoc dynamic temperature checks which can happen at any givenmoment.This presents info to a coordination/moderation team, who hopefully makesfair decisions. Here is an example of how the GA can directly manage theprocess:In Boulder they are working on using Twitter as a back channel forevaluating the current speaker - over VoIP. This was my suggestion, butwithout the reputation element:A primitive version of ConsensusVoIP (CV) would support the followingtweets:Support2-Addition or correction offeredSupport1-Additional information neededSupport0-Sounds goodOppose3-Do not understandOppose2-Not sincere, Joke, etc.Oppose1-FalseOppose0-Waste of timeAs a speaker finishes, the total of "Support" vs. "Oppose" tweets iscomputed. If there are more Oppose tweets, then the highest priorityoppose, Oppose3, is selected for processing (Oppose0 is not a block andtherefore not a request to speak?). Of those who have tweeted Oppose3, aperson is randomly selected as the next speaker. CV would then speak thename and priority/objective. For example, Bob-Oppose1 yields "Bob sees anerror" as an introduction from CV.It will probably be necessary to use a server for the VoIP, so the backchannel could go back to it. This could be a lot more secure then tweeting.Another approach would be switch modes once Support tweets reached2/3rds. Then Oppose inputs would be given the highest priority to see ifall blocks could be eliminated.I describe how effective time management could be added to this type ofprotocol:Stodolsky, D. (1984, December). Self-management of criticism in dialog:Dynamic regulation through automatic mediation. Paper presented at thesymposium Communicating and Contracts between people in the ComputerizedSociety, Gothenburg University, Sweden.This model issues invitations to respond based upon peoples' reputations.Extended abstract (5 min. read):Stodolsky, D. S. (2002). Computer-network based democracy: Scientificcommunication as a basis for governance. Proceedings of the 3rdInternational Workshop on Knowledge Management in e-Government, 7, 127-137.ComprehensiveStodolsky, D. S. (1995). Consensus Journals: Invitational journals basedupon peer review. The Information Society, 11(4).dssDavid Stodolsky, PhD Institute for Social InformaticsTornskadestien 2, st. th., DK-2400 Copenhagen NV, Denmarkdss@socialinformatics.org Skype/Twitter: davidstodolsky_______________________________________________Ows_solutions mailing listDavid Stodolsky Blog: http://firstname.lastname@example.org Skype/Twitter: davidstodolsky_______________________________________________Occupy-dev mailing list_______________________________________________
Occupy-dev mailing list
Occupy-dev mailing list
|< PREV||INDEX||SEARCH||NEXT >|