<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Courier New">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. <br>
<br>
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.<br>
<br>
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. <br>
<br>
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.)<br>
<br>
<br>
Thomas<br>
<br>
<br>
<br>
<br>
<br>
</font><br>
On Fri, 20 Apr 2012 10:55, Michael Allan wrote:
<blockquote cite="mid:1334904974.5AeE66DC0.27135@out.zelea.com"
type="cite">
<pre wrap="">Welcome David,
David Bovill said:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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. :-)
</pre>
</blockquote>
<pre wrap="">
Can you elaborate on this?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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] <a class="moz-txt-link-freetext" href="http://zelea.com/w/Category:Account">http://zelea.com/w/Category:Account</a>
[2] <a class="moz-txt-link-freetext" href="http://zelea.com/w/Wiki:Vote_count">http://zelea.com/w/Wiki:Vote_count</a>
</pre>
</blockquote>
</body>
</html>