Group definition in transitive vote flows

[Michael Allan]

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

-- 
Michael Allan

Toronto, +1 416-699-9528
http://zelea.com/