Rapid deployment of Votorola

[Michael Allan]

Hey Thomas,

Here's the proposal I mentioned.  This would supercede the plan of
setting up a pollserver hosting service.

This is a proposal for increasing Votorola's speed of deployment.  The
goal is to ensure that Votorola can keep pace with the rollout of the
common voter register (streetwikis and trustservers).  It takes almost
no effort to set up a streetwiki.  So the overall register (T,S) might
deploy rapidly across a wide area, creating a surge in demand for
voting facilities.


       (T)            (T)
       /|\            /|\       
      / | \          / | \      
     /  |  \        /  |  .     
    /   |   \      /   |   .    
  (S)  (S)  (S)  (S)  (S)     -> deploy      T = Trustserver
                                             S = Streetwiki
  (P)  (P)  (P)                              P = Pollwiki
   |    |    |    .                          V = Voting engine, or
   |    |    |    .                              Votorola pollserver
   |    |    |    |
  (V)  (V)  (V)  (V)


    FIG 1.  The problem is that voting engines (V,P) cannot keep pace
            with deployment of the register (T,S).


The problem is that, in order to keep pace, we require a new
pollserver/pollwiki pair (V,P) for every streetwiki that pops into
existence (fig. 1).  That's not so easy.  It takes a technically
skilled administrator to set up a pollserver.  Then the administrator
probably has to do the initial work of defining electoral districts,
too.  It's a lot of work, up front.

The proposed solution (obvious when it's layed out like this) is to
copy the trustserver's trick of deployment.  Each pollserver (V) now
serves multiple pollwikis (here we show 3 or so, but in practice the
number would be higher).


       (T)            (T)
       /|\            /|\       
      / | \          / | \      
     /  |  \        /  |  .     
    /   |   \      /   |   .    
  (S)  (S)  (S)  (S)  (S)    ->

  (P)  (P)  (P)  (P)  (P)
    \   |   /      \   |   .
     \  |  /        \  |  .
      \ | /          \ | /
       \|/            \|/
       (V)            (V)       


    FIG 2.  Part of the solution, multiple P per V.


We can then go one step further, and push the functions of Votorola's
pollwiki into the common streetwiki (fig. 3).  These functions
include:

   i. District definition
  ii. Issue/poll definition
 iii. Position drafting

The first two are common information anyway, so it makes sense to put
them in the streetwiki.  But the third also fits, because it gets
tucked away in the user's own subpages.  Presumeably only Votorola
users will be creating position pages.  No problem.


       (T)            (T)
       /|\            /|\       
      / | \          / | \      
     /  |  \        /  |  .     
    /   |   \      /   |   .    
  (S)  (S)  (S)  (S)  (S)    ->
    \   |   /      \   |   .
     \  |  /        \  |  .
      \ | /          \ | /
       \|/            \|/
       (V)            (V)


    FIG 3.  The rest of the solution, P merged into S.


As each new streetwiki S comes online, it is immediately served by an
existing pollserver V.  In less than a day, an ordinary (non-tech)
user can:

  1. Set up a new streetwiki
  2. Get a few people registered
  3. Extend trust and get them authenticated
  4. Open a local issue (electoral or normative)
  5. Vote using the engine of choice (only Votorola shown here)
  6. See the results mirrored across all engines

Beyond the local level, there is a second tier composed of
"statewikis" (A).  Unlike streetwikis, statewikis do not have a
registration function.  Rather, they serve mainly for navigating among
related streetwikis.  For example, each A might serve a different
German state.  Each would provide maps to show the location of the
towns and regions under its jurisdiction, with links to their
streetwikis; or an invitation to set one up, if there is none (as you
suggested earlier).


  (S)  (S)  (S)  (S)  (S)
    \   |   /      \   |   .
     \  |  /        \  |  .
 \ |  \ | /  | /  |  \ | /
  \|/  \|/  \|/  \|/  \|/                    S = Streetwiki
  (V)  (V)  (V)  (V)  (V)                    A = Statewiki

  (A)  (A)  (A)  (A)  (A)     -> deploy
    \   |   /      \   |   .
     \  |  /        \  |  .
      \ | /          \ | /
       \|/            \|/
       (V)            (V)


    FIG 4.  Beyond the local level (top), the functions of P are
            merged into common statewikis (A).

So the statewiki is where (ii) statewide issues are defined, and where
(iii) users keep their position drafts for the statewide polls.  An
ordinary user can set up a statewiki if one does not already exist,
and start voting that day.  (And so on, for the national and global
tiers.)  Like S, each A is seamlessly forkable.

We'd still need to do some work in Votorola.  But it could probably be
done in week-long chunks, as needed.  There should be no lengthy
delays up front.

What do you think?  (Others too?  Please comment if you have time.)
I haven't thought it all through.  I may be missing something.

-- 
Michael Allan

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