Meta-Tool

[Michael Allan]

I was originally saying what Friedrich says: it's premature to talk
about vote pooling, and it's hardly feasible anyway.  But I eventually
came to agree with Thomas.  It's not premature at all.  There are two
immediate problems (two sides of the same coin) to address: split
consensus among voting engines, and irrational competition.  I added
brief explanations to the intro here:

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

Friedrich Lindenberg wrote:
> Of course we'll have to talk about interoperability in the long term,
> but right now there is just no basis for a debate based on empirical
> experience. Let me take your vote mirroring proposal as an example:
> you don't discuss different kinds of voting systems, preference voting
> v. binary voting, security, synchronization and timing issues, etc.
> etc. Essentially this is a proposal for the replication of Votorola
> pollserver state in a controlled environment, but that's it.

None of this is properly documented yet, so it's not easy to see.  But
I think it's the opposite of what you say.  I think autocast mirroring
is both a practical solution, and also universal.  On the practical
side, autocasting simply doesn't raise any issues of timing and
security that aren't already raised by manual casting.  How could it?
The autocaster is a bona fide agent, a stand-in for the user.  It can
do whatever the user does, only faster.

Universality isn't a problem, either.  The native engine retains the
original vote.  The other engines get a thin translation that's
entirely dependent (mirror-like) on the original.  So there's no loss
of info.  At the same time, there's no ugly standards-stew of common
vote representations.  Mirroring is an elegant solution compared with
pooling.

It's robust, too.  Some kind of translation is usually going to be
possible between any two voting methods (X,Y), provided you don't have
to worry about the reverse translation and (crucially) the attendant
loss of info.  What pair (X,Y) can't we code a one-way translation
(X->Y) for?  For that pair, any engine using Y will be blind to the
votes of engines using X.  That's all, the system won't fall apart.
It's robust.

The autocaster is also something that a developer could start working
on tomorrow.  The interfaces it needs the most (vote monitoring and
vote casting) won't be hard to agree, because they're pretty narrow.
And once it's coded, there's no lack of alpha voting engines to test
it on.  The testing will be a draw for users, and the kind of thing -
like David says - that can snowball to everyone's advantage.  (But
mirroring won't really come into its own till we have common
registers.  So I guess this is a good use case for the registration
framework, too.)

-- 
Michael Allan

Toronto, +1 647-436-4521
http://zelea.com/