What we need right away

OK... we have volunteers for some things. But other things are missing
still. The big things that NEED people to lead the subprojects:

 * The Blind-Accesible Ballot System

   All I know now is that it will produce the same 'vote-selection.xml'
   output data as the Standard Ballot System (and use the same
   ballot-electin.xml input). Please, someone agree to "own" this
   subproject (or recruit someone who can).

 * The Barcode Vocalization System

   Same story, basically. I don't know anything about what's needed. I
   suppose recorded and/or synthesized voices. But I need someone to
   "own" this task.

A couple smaller things that need doing. These aren't so much a matter
of ownership, as just sitting down and doing them.

 * Decide the format of vote-selection.xml. The purpose of this data
   file is to represent the votes cast by a individual voter. It WILL
   include the ballot-id (see Architecture, "The encoding of cast
   votes"). It will also include all the races; the trick here is that
   the format needs to be XML, *AND* it needs to be flexible enough to
   encode every type of race or contest that can occur on ballots (not
   just those on the demo; although I do not specifically know of other
   types). Ideally, we should also have a vote-selection.dtd to
   accompany a sample; but that's less urgent, and we can do it later if
   need be.

   To do this, we need both someone comfortable with XML, and someone
   who knows ballots. The latter is either Alan, Doug or Arnie, most
   likely. The former, I dunno? This isn't particularly *complicated*,
   it just needs to be done. No committees, no big discussion, just
   someone write one down and let us know it.

 * Convert the vote-selection.xml data file into a digit string, no
   longer than 60 decimal digits long. The encoding most certainly will
   be specific to the particular ballot being used in the election at
   hand. For example, we are assumed to know at both ends that e.g.
   race 1 is "PickOneofNine", while race 5 is "PickFourofSeven"; so that
   fact need not be itself encoded. See Chris' discussion of the
   information needs of different contest types (and my minor addendum).

   Just as a quick example, a reasonable encoding might be:

     ballot-id race1 race2 race3 race4 race5 ...
       dddd d dd ddd dd dddd ...

   That is, I know one digit suffice for race 1 (non-selection can be a
   '0'). Hypothetically 2-4 need the number of digits shown (I dunno
   why). And race 5 encodes the canditate numbers of each of the (up
   to) four allowed (if fewer choices are permitted, we might use '0's
   for non-selections). I'm not demanding this encoding, but this is an
   example (it is easy to decipher and understand, but not too verbose).

   This 60 digit number is what will go on the barcode. Jan is
   handling the printing aspect, but let's be nice and hand him the
   digits he needs. Whoever does this might want to chat with Jan and
   Chris, in case coordination is needed.

   Call this utility or function something like 'votes2digits'. It
   should take an XML file as input, and output a 60 digit string
   (perhaps a shorter one, but no longer). Use gnosis.xml.objectify to
   make walking the XML data painless.

Yours, David...
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Tue Sep 30 23:17:05 2003