Rapid prototyping of an open voting architecture

[Michael Allan]

This post is transcribed from the wiki text:
http://t.zelea.com/wiki/User:Mike-ZeleaCom/Opening_an_architecture#Rapid_prototyping

In recent discussions off list, it was suggested that rapid
prototyping might be used to implement an open voting architecture,
as a temporary measure, prior to a full-scale design effort.  This is
a description of the implementation method.  In summary:
(1) registration data are posted to the Web in a flat file;
(2) voting engines read the data to compile their voter lists;
(3) votes of each engine are likewise posted in flat files; and
(4) other engines read the vote data and image the votes.
These hacks should suffice to implement the use case of free-range
voting in as little as 3 weeks.

Method
------

 1. Create a register of the voters who are eligible to vote on
    architectural design documents. ^[1][2]

    a) In a wiki, create a list of e-democracy projects.

       Define the criteria for inclusion in the list.  For example, a
       project must have running code (alpha or later), and must be a
       participant in the prototyping effort. ^[2]

    b) Under each project, enter the names of up to 4 individuals who
       are eligible to vote.  These individuals will typically be
       contributors to the project.  The limit of 4 is intended to
       equalize the representation across all projects (large and
       small).

       The length of the resulting *registration list* is 4P or less,
       where P is the number of projects.  This is short enough that
       sock puppets are easy to detect.  The list may therefore claim
       to be *tight*.

    c) Under each name, enter that individual's *personal identifiers*
       (OpenID, email address and engine-specific usernames).  Cover
       whatever identifier formats are used by the participating
       voting engines.

 2. Code the *voter list* compilation for each engine.  This is a
    temporary hack for the list compiler. ^[1]

    a) Copy the registration list from the register (1).

    b) Translate the registration list to the engine's native
       voter-eligiblity format.  The result is effectively a voter
       list for that engine.  Its content will be equivalent to that
       of the other engines' lists.

    c) Recompile the list periodically, as needed.

 3. Code the export of *original votes* from each *source engine*.
    This is a temporary hack for the *vote monitoring* interface.  For
    each architectural document at issue: ^[3]

    a) Create a new poll (aka. "issue").

    b) Export all of the poll's original votes to a text file (vote
       list).  For each original vote in the list, record the
       particulars that define it.  The exact format will depend on
       the engine's voting method, but just as an example:

          i. Subject identifier (voter)
         ii. Object identifier (delegate or proposal)
        iii. Timestamp ^[4]

    c) Post the vote list to the Web at BASE_URL/ISSUE, where BASE_URL
       is the URL for all of the engine's vote lists; and ISSUE is a
       pre-agreed universal identifier for the prospective issue
       (i.e. for the architectural document).

    d) Re-export the vote list periodically, as needed.

 4. Code the *pull mirroring* on each *destination engine*.  This is a
    temporary hack for an autocaster.  For each source engine (3):
    ^[3]

    a) Copy the vote list from the source engine.

    b) Translate each original vote to an *image vote* in the
       destination engine's native format.

    c) Re-pull the vote list periodically, as needed.

 The shared voter registrations (1,2) will enable the developers (as
 users) to wander from engine to engine, without restriction.  The
 vote mirroring (3,4) will effectively pool their votes across all
 engines.  Thus free-range voting may be implemented in alpha
 prototype.  Developers may use the prototype to vote up the design
 documents, even while they develop the code to the specifications of
 the design.  Later, when residential registers are brought online,
 voting may be extended to the general public.

Notes
-----

 [1] http://t.zelea.com/wiki/User:Mike-ZeleaCom/Registration_framework

 [2] The general category of voted issues and the eligibility criteria
     for the voters do not really matter.  But voting on the
     architectural documents (as the issue) has the advantage of
     enabling the developers to eat their own dogfood.

 [3] http://t.zelea.com/wiki/User:ThomasvonderElbe_GmxDe/Vote_mirroring

 [4] Timestamping of exported votes allows for older originals to be
     replaced by newer images.


Comments and critique are welcome,
-- 
Michael Allan

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