[MG] Cascading agreement, money, communities and other resources in votespace

Ed Pastore epastore at metagovernment.org
Sun Jun 12 08:47:13 EDT 2011


Thanks, Michael. Your description below helps clear it up some. It is  
quite clever, however I can also see it being quite difficult to get  
across to the average person. I'm somewhat close to the issues and I  
am still having a hard time grasping it. I think more examples (use  
cases) may be helpful here.

Which brings me to Thomas' use-case:

> A community has no kindergarden but wants one. They start a poll and  
> many different plans emerge of how it should be like, where exactly  
> it should be located etc. Every plan expresses the amount of the  
> different necessary resources for its realization, i.e. votes,  
> money, land, labour, bricks, wood, ... And now all the people voting  
> for a paricular plan can express what recources they are willing to  
> contribute. And the count-engine counts them all up. So everyone can  
> see, what is still missing and what not. If the count reaches 100%  
> the plan can be executed, all the resources are there. Happy  
> parents, happy children! :-)

How does this account for the person who doesn't want a kindergarden  
near their house for whatever reason? This model seems to be centered  
around adhocracy-like building of projects by efforts of the willing,  
but I don't see where it allows for people who are actively opposed to  
the project in the first place. A kindergarden is a little hard to  
imagine someone opposing if they don't even have to pay for it, but  
how about building a dam, which will radically alter the flow of water  
downstream?


On Jun 6, 2011, at 12:43 AM, Michael Allan wrote:

> Ed and Thomas,
>
> Ed Pastore wrote:
>> I'm trying to catch up on my backlog of reading, and the below looks
>> both fascinating and baffling. I'm trying, but I've lost the thread
>> of what's going on here. Could one of you try to bring this down to
>> earth a little and explain where you are? I'd be happy to work on
>> some documentation (or at least description) as a learning exercise,
>> but I'm not able to do that from posts like the below.
>
> These are the main ideas as I see them.
>
> (a) Expose the resource needs, expectations and fulfilments of each
>     collective effort as a "message" to the larger public sphere.
>     Express that message in terms of the social space of the effort
>     itself (b).
>
> (b) Show the resources flowing together with the votes of the
>     participants in the same way that agreement flows into consensus.
>     Agreement is just a kind of resource.
>
> (c) Consider that extension within the larger public sphere is
>     another kind of resource that an effort needs.  By "extension", I
>     mean participation that covers many separate communities.  When a
>     collective effort needs, expects and is working toward extension,
>     then let it say so.
>
> (d) Let the periphery decide the resource needs.  Trees and branches
>     of the collective forest are free to decide for themselves what
>     resources are required for the overall effort.  (We floated this
>     idea yesterday in offline discussion, C, Thomas and me.)
>
>     Our example concerns the problem of littering in the streets.
>     The leading candidate defines it as a legislative matter for the
>     city and is gathering votes for a bylaw (resource = agreement)
>     that will impose fines, or something like that.  A delegate in a
>     higher branch disagrees and instead defines it as a local
>     community effort (resource = agreement + labour) with
>     participation restricted to the residents of the local
>     neighbourhood, but simulaneously expanded to include non-citizen
>     residents.  The count engine will take care to ensure that the
>     labour pledges and non-citizen votes do not cascade past the
>     delegate and into the bylaw drafts below, while the local
>     citizens' votes do.  (In practice, this particular delegate would
>     be better off as an end candidate, so this is a contrived
>     example.)
>
>     We recognize that this freedom of delegates to redefine the issue
>     means that a single poll may sometimes come to house two issues
>     that really ought to be separate.  The problem then becomes the
>     coordination of the move of one branch or tree to a separate
>     poll.  Moving an individual position is easy, so the only problem
>     is the social coordination of the individuals.  Therefore the
>     delegates will solve this.
>
> (e) Let the periphery decide what resource message to expose (a).
>     Clearly this is required when the resources are completely
>     redefined by the periphery, as in the example above.  But here is
>     another example:
>
>     One branch of the "street littering" tree is drafting a radically
>     different version of the bylaw.  They only have a few votes but
>     they feel they have the capacity to grow among certain
>     communities in the city.  So they identify inter-community
>     extension as a crucial resource (resources = extension +
>     agreement) and go to work at it.  Naturally they expose this as
>     their public resource message.  They need help in order to extend
>     to other communities, so they ask for it.
>
> Thomas von der Elbe wrote:
>> Interesting! Yes I think it will work. But to show the number of
>> active communities in the vote-space is additional to the other 4
>> maps, right?
>
> I think the other 4 maps (graph/table maps) are now secondary.  They
> are likely still needed, but not front and center.
>
>>> Now to communities: As we've discovered, the crucial resource in
>>> the beginning is not actually agreement or money, but rather the
>>> talk itself.  Unless the conversation can extend over a sufficient
>>> number of communities - spread its wings and fly - it dies.  So
>>> the content we need to show is the number of active communities
>>> over which each branch or tree of votespace has extended itself.
>>> We want the first time viewer to realize, "Ah, I see!  These
>>> people are growing an extended conversation."
>>
>> But here too: the content of the drafts plus the votes plus the
>> number of communities ... all together, right? Or do you picture it
>> as seperate?
>
> The "2 second" message is focused on inter-community extension in this
> case.  Votespace is tailored accordingly.  I figure we show only the
> count of active communities (or whatever) and not the count of votes.
>
> I guess we'd provide a control for the user to switch resources.  For
> most of the forest in example (4), there would only be the one
> resource, "agreement" as measured by votes.  But some branches would
> also allow "extension" to be selected as a resource, and others would
> allow "labour".  And so forth.
>
> Thomas has concerns about (c), and I try to factor them out here:
>
> (1) That we should pioneer the practice of extension manually, so to
>     speak, without tool supports.
>
> (2) That tools might not be needed for this practice at all.
>
> (3) That the practice is only useful during the early adoption phase
>     of the technology.  Once the first poll hits the news, nobody
>     will be worried about extension anymore.
>
> (4) That it's wasteful to develop tools that are likely to be
>     outmoded so soon.
>
> I agree with (1) and disagree with the others.  But did I state these
> correctly, Thomas?
>
> -- 
> Michael Allan
>
> Toronto, +1 416-699-9528
> http://zelea.com/
>
> _______________________________________________
> Start : a mailing list of the Metagovernment project
> http://www.metagovernment.org/
> Post to the list: Start at metagovernment.org
> Manage subscription: http://metagovernment.org/mailman/listinfo/start_metagovernment.org




Originally posted to the mailing list of the Metagovernment Project:
http://metagovernment.org/mailman/listinfo/start_metagovernment.org



More information about the Votorola mailing list