Meta-Tool

[Michael Allan]

David, Martin, Thomas,

David Bovill wrote:
> Yes - I think I get it. Quick question is this any different form
> providing "vote casting" messaging API, that any implementation can
> post to and optionally subscribe to?

Not by much.  It's just there are other APIs, too.  I updated the
diagrams.  So here's the simplest setup:

  http://t.zelea.com/wiki/User:ThomasvonderElbe_GmxDe/Vote_mirroring#Pull

Engine A exposes a "vote monitoring" interface (a messaging API, like
you say) to which any number of clients may subscribe (maybe over XMPP
transport).  The sole subscriber in this case is the autocaster, and
it uses the interface to mirror the votes on its local engine (B).  So
B gets all the same voters as A.  (Interestingly, B has no users yet.)

A poll identification service is also needed (right).  It maps poll
identity between the two voting engines.  So the autocaster knows
where to shunt the incoming mirrored votes - this vote goes to the
property tax poll, this to the foreign policy directive, and so on.

Also, the voting engines share registers in common (left).  These are
required to determine voter eligibility, as Martin brings up (below).

Martin Häcker wrote:
> ... But in the end, each voter casts one vote for one issue. (Does
> this leave preference based voting methods out?)

Maybe we can get away with vote translations like the following:

  * From ranked to single (R->S), the autocaster takes the top-ranked
    R as the single choice S

  * From single to ranked (S->R), it marks the single choice S as the
    only choice on ranked ballot R

It's up to the coders, of course.  (It'll be kind of fun watching
these things run.)

> That is actually a pretty nifty description of delegation - you have
> an agent that you tell whose *open* voting decision you trust - and
> it votes the same.

Neat trick!  No need to code a delegate voting method, it's all done
by push autocasting.  So in general, because the autocaster already
knows how to mirror-translate methods (A->B) across engines, it can
also simulate A-like votes entirely within engine B.  The coders of B
don't have to know anything about method A.

> Still I would be very cautious to mirror votes into other systems -
> besides just showing whats happening elsewhere, as there are also
> social issues at play.
>
> Consider a small organization using a liquid tool [B] to find out
> what they want - if their decisions are swamped by votes from other
> systems [A] - it is pretty easy to loose the boundaries of the group
> and generate a lot of antipathy against the system where other
> people tell them what to do.

If that were a problem with autocasting, wouldn't it also be a problem
with manual casting?  Either the voter from engine A is eligible to
vote on B, or she is not.  If she is not eligible, then it doesn't
matter how she cast her vote (manually or autocast) it will be
rejected all the same.

Eligiblity is determined by membership in B's voter list.  The voter
list is compiled from the registrations of the common voter register
(or registers).  If the registers aren't common between A and B, or if
the voter's registration properties don't meet the requirements for
inclusion in the voter list, then the engine will discount her vote.

http://t.zelea.com/wiki/User:Mike-ZeleaCom/Registration_framework#Use_cases

Thomas mentions client filtering of results, which is ideal for this.
But it's not practical, yet.  It takes too much computer steam.  (On
the other hand, maybe that's what the meta-tool is doing?  It could
run on the desktop, so lots of steam.) ^[1]

> So it might be entirely reasonable to aggregate votes of different
> system in a meta-system where you can get an overview of what people
> in groups larger than one organization say.

Thomas von der Elbe wrote, in reply:
> I can imagine, that this part technically actually doesn´t require a lot 
> from the single systems. It would just be a continuous export of data, 
> which exist inside the systems anyway. Am I guessing right?

I think so (if you ask me).  It's just a feed.  Autocast mirroring
(pull mode) can handle the use case of the meta-tool.  Here it is:

 [1] This could also be the setup of a meta-tool (portal or shell).
     Pretend that the voting engine from supplier B isn't actually a
     voting engine, but rather a meta-tool installed on the user's
     desktop.  In this case, it's a simple view-only shell that does
     nothing but mirror the votes.  It mirrors them for purposes of
     specialized analysis and presentation, or for an aggregate
     overview across polling sites.  Later, the coders may add other
     features and integrate other facilities, till they've got a
     full-blown voter shell.

     Maybe this thing could also do user-customized recounts, with
     vote filtering and all.  I didn't think that would be practical
     for a long time, but maybe it's not so far off.

-- 
Michael Allan

Toronto, +1 647-436-4521
http://zelea.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: collab-pull.png
Type: image/png
Size: 45405 bytes
Desc: not available
URL: <http://list.reluk.ca/list/votorola/attachments/20091206/c1d9f5ca/attachment-0007.png>