[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