Some comments

[Michael Allan]

Hi David,

> I have searched for any actual applications (in the real world) but
> haven't seen any.. Has this system been tried anywhere?

Votorola itself hasn't been used in real life.  It's still in alpha,
and the usability trials are still ahead.  There are maybe two other
recursive voting systems.  They say that Demoex was the closest to
getting real public exposure.  I'm not sure what kind of exposure it
actually got:

  http://en.wikipedia.org/wiki/Demoex
  http://demoex.net/

I don't really know anything about it though.  The trail is hard to
follow.  It goes from Swedish to Italian here:

  http://demoex.net/node/1225

Giovani Spagnolo recently told us that his TelematicsFreedom code was
partly based on old Demoex code.  I don't know what stage he's at with
it.  He was applying for EU funding.  (I suspect it's pre-alpha, but
don't know.)

Marko Rodriguez et al. had a different system called Smartocracy.  It
was a lightweight experimental voting engine.  They they did some
trials of recursive delegation with it, involving non-political
decisions.  This is the latest of their papers, I think:

  http://www2.computer.org/portal/web/csdl/doi/10.1109/HICSS.2007.484

> I'm curious if you could do a rough simulation in a room with 10
> people making a decision and exchanging paper tokens. Contrasting this
> simpler idea may make it easier to explain.

It's a good approach to take (I agree with Thomas).  It's a good
design exercise too, even just as a thought experiment.  There's a
catch though.  The purpose of the tool is to scale up a process that -
at a small scale - requires no tool support at all.  It would be nice
to demonstrate and explain that scalability.  (I have an idea on how
to do it.  I'll post it soon.)

> A few comments about the code base. It is evident the developer (hi
> Michael) is very experienced and has focused on important parts, and I
> don't want to sound presumptuous. But last I looked, the code base
> would be more difficult for a third party to participate in because it
> uses a mix of languages (Java and Perl), is platform specific
> (requires *nix), one specific database (Postgres) and the low level
> code (database, etc) is mixed with high level application code through
> exceptions, for example (and the domain code has some pretty low level
> stuff in it). None of this would be difficult to fix, for example,
> switch to Ant or Maven (and use a more standard, comprehensible at a
> glance layout), use a database interface or at least alternatively
> support a self contained database like JavaDB/Derby, and use
> RuntimeExceptions (that still throw a stack trace) when appropriate.
> This would result in a code base that is easier for people to
> participate in, and as importantly set up, with one click installs on
> any operating system being possible.

Thanks for looking at the code.  I favour a general purpose language
for flexibility (so Perl instead of Ant).  But that's just me, and I
could be outvoted.  I'm not an experienced DB developer at all.  If a
cleaner separation is possible, I agree, it's generally a good idea.
I agree too, we have to make the installation as painless as possible.
The admins will demand it.  Even if central hosting is available (see
Paul's recent thread) not all of them will use it.

On portability: The code is mostly portable in its design.  The impl
has dependencies.  Some of these are just temporary compromises to
save dev time.  The admin procedures in the system manual are
currently doc'd only for Unix, and that's maybe where most of the
dependencies are going to creep in.  Admin is going to be pretty
intensive on both the tech and social sides, and will need lots of OS
supports and external tools, I'm thinking.

> Again I recognize that the developer may have made this choices
> because the code base isn't ready for popular use. With encouragement
> I'd be willing to work on these aspects of the system.
> 
> I'd be interested in participating in, supporting or just learning
> about any applications (and eventually support local applications).
> I'm located in Montreal and travel frequently to Toronto.

You're thinking of making the project more attractive to developers.
That sounds like a good investment, a good bet to pay off.  But the
project's wide open, too.  So you're free to tackle anything that
interests you.

Best,
-- 
Michael Allan

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