Rapid deployment of Votorola

[David Bovill]

Will comment properly later - have been working on server infra-structure
and services for a similar national / regional / one-click install set up -
so this may mirror nicely!

On 8 February 2010 17:22, Michael Allan <mike at zelea.com> wrote:

> 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.reluk.ca/list/votorola/attachments/20100211/9b437e84/attachment-0007.html>