Group definition in transitive vote flows
Thomas von der Elbe
ThomasvonderElbe at gmx.de
Sun Apr 22 06:51:40 EDT 2012
Lately I have been thinking a lot about how to start a poll. I always
thought, I had a clear picture of how Votorola could be used and behave
with large numbers of voters and imagined it to be the same for low
numbers in the beginning of a poll. I think I was wrong in both regards.
Because, if it was natural, nobody would have to vote in the beginning.
People just meet and express their positions to each other. No voting,
no delegation, but lots of talk and exchange of ideas, positions, ...
Ofc, at some point people will want to group together to express their
common view. But naturally it would not be behind a delegate. (A
delegates only purpose is to represent a group to the next deeper
delegate. But in the core group there is no further delegate, so he is
useless.) Naturally they would just draft a common position together,
still each having their own positions too. Just a group of people
together editing a wiki-page or a pirate-pad (ether-pad). Now this page
could run under Mikes proposed group-email-adress. At some point the
discussion will get to crowded, to noisy ... so the natural solution
would be: "People! Group together behind positions and choose
representatives! Only those with at least 2 votes are from now on
allowed to talk and to edit the common page!" and so on up the numbers
and up the tree.
This extreme case of the beginning of a poll makes a problem visible,
which I didn't see before: the role of delegate which himself wants to
be voter too. Two possibly contradictory roles. With the creation of
such group-positions, these roles are seperated, as they belong. One can
be elected as the groups representative, but at the same time remain its
voter.
So one result of this for me: the creation of a position is the main
entry-point into a poll, not the voting. This should be valued more in
the software. Maybe we could give each drafter a vote for his draft and
count it ... feels also natural. Or if the count-engine is strictly for
delegation, then maybe count the drafters in the wiki, so we have a
number of participants in the poll. (Again, I'd rather encourage them
not to vote, but just to draft in the beginning.)
Thomas
On Fri, 20 Apr 2012 10:55, Michael Allan wrote:
> Welcome David,
>
> David Bovill said:
>>> There are problems with a cycle:
>>>
>>> a) Only end-candidates can cycle. If folks up in the tree form a
>>> cycle, they drop to the ground like ripe fruit. :-)
>> Can you elaborate on this?
> Maybe a puzzle is the best way. Here are two trees. One (t) is
> suspended above the other (b), temporarily defying gravity. The task
> is get the votes of (t) flowing down into (u), thus forming a single
> tree in which (t) occupies the higher branches.
>
>
> (V) (W)
> | |
> | |
> (C) (D) (E) (F) (G) (H) (t)
> \ \ | / / /
> \ \ | / / /
> \ \|/ / /
> +-+ | +-+---+
> \|/
> (J) |
> | vote flow
> V
> (X) (Y)
> | |
> | |
> (L) (M) (N) (O) (P) (Q) (b)
> \ \ | / / /
> \ \ | / / /
> \ \|/ / /
> +-+ | +-+---+
> \|/
> (Z)
>
>
> The solution is trivial, of course. Simply extend a vote from (J) to
> (Y), or to any other node of (b). For example:
>
>
> (V) (W)
> | |
> | |
> (C) (D) (E) (F) (G) (H) (t)
> \ \ | / / /
> \ \ | / / /
> \ \|/ / /
> +-+ | +-+---+
> \|/
> (J) |
> | | vote flow
> | V
> (X) (Y)
> | |
> | |
> (L) (M) (N) (O) (P) (Q) (b)
> \ \ | / / /
> \ \ | / / /
> \ \|/ / /
> +-+ | +-+---+
> \|/
> (Z)
>
>
> Here is the same puzzle, except with the ordinary tree (t) replaced by
> one with a cyclic root (u).
>
>
>
> (V)---(C)
> / \ (W) (u)
> (H) (D) /
> | | /
> (G) (E)
> \ /
> (F) |
> | vote flow
> V
> (X) (Y)
> | |
> | |
> (L) (M) (N) (O) (P) (Q) (b)
> \ \ | / / /
> \ \ | / / /
> \ \|/ / /
> +-+ | +-+---+
> \|/
> (Z)
>
>
> This version of the puzzle cannot be solved without breaking the
> cycle. Generally no cycle can form in the higher branches of a tree.
> Every cycle must fall to the forest floor, where it forms the root of
> a separate tree.
>
>>> A possible solution [for an impersonal candidate] is to give the
>>> group an email address (P), then vote for the group:
>>>
>>>
>>> (V) (W) (0) (0)
>>> | | | |
>>> | | | |
>>> (C) (D) (E) (F) (G) (H) (1) (0) (1) (0) (0) (0)
>>> \ \ | / / / \ \ | / / /
>>> \ \ | / / / \ \ | / / /
>>> \ \|/ / / \ \|/ / /
>>> +-+ | +-+---+ +-+ | +-+---+
>>> \|/ \|/
>>> (P) (8)
>>>
>>>
>>> This is almost the same, but with none of the disadvantages. All
>>> we'd need is a small change in the count engine to allow
>>> non-eligible voters (like P) to carry votes. (Currently they can
>>> only receive votes, but cannot cast or carry.) Then the whole
>>> group could "vote" for someone else, or for another group. That
>>> means it could exist higher up in the tree.
>> This is I think how I see it. I see many use cases for such groups,
>> and would like to see a way in which they can form and dissolve in a
>> way which is not too traumatic. Inside the group there would be an
>> internal vote, and indeed they would be able to adopt different ways
>> of organising this - they could nest an LD system within the group
>> node or adopt another simpler voting system.
> Yes, the introduction of the impersonal, subjectless group node raises
> the problem of how to control its resources, if only the single
> resource of the group vote. It seems natural to let the group members
> themselves solve this problem, as you suggest. Note here that group
> membership is formally defined to include all those who cast votes
> into the group subtree.
>
> This raises an interesting question: Might the group take control of
> its own membership? By definition, they would need control of voter
> eligibility for this. The RAC resource accounting framework [1] that
> C and I are designing offers a possible solution. In the RAC, the
> vote count is just one type of resource account [2]. All resource
> accounts are administered in distributed fashion, such that any node
> in a tree may redefine the properties of any account *for its branch*
> of the tree. So imagine the general "Votes" account includes a "voter
> eligibility criteria" property. The group could then control its own
> membership by setting that property at the group node (J, below), thus
> effectively saying, "only members of the Jacuzzi Enthusiasts Club", or
> "only residents of Jakarta". So a branch of the tree might define
> itself by more than voluntary association.
>
>
> (V) (W)
> | |
> | |
> (C) (D) (E) (F) (G) (H) (t)
> \ \ | / / /
> \ \ | / / /
> \ \|/ / /
> +-+ | +-+---+
> \|/
> (J) |
> | | vote flow
> | V
> (X) (Y)
> | |
> | |
> (L) (M) (N) (O) (P) (Q) (b)
> \ \ | / / /
> \ \ | / / /
> \ \|/ / /
> +-+ | +-+---+
> \|/
> (Z)
>
>
>
> [1] http://zelea.com/w/Category:Account
> [2] http://zelea.com/w/Wiki:Vote_count
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zelea.com/list/votorola/attachments/20120422/c80a8462/attachment.html>
More information about the Votorola
mailing list