To allow a voting advice network to form and expand on its own, the organization must act as as standards body. It must also provide an initial reference implementation to get the ball rolling and to serve as a model for others to build on. In addition, it must engage in public outreach , and eventually provide support services, in order to promote system adoption.
A voting advice system needs a way to give advice, a way to receive it, and a way to store it for later access. To be robust, the system needs to allow for multiple implementations of the programs that do so. To make that happen, they all need to be communicating using common standards. Arguably the most important mission of the organization, then, is to codify and coordinate those standards.
This part of the effort aims to increase awareness of the system, and to increase adoption by both advice givers and advice receivers, until the system is effectively running on its own.
As adoption grows, the organization will also need to provide support services to developers who are engaged in creating augmented versions of the reference implementation.
The reference implementation serves as a proving ground for the inter-operability standards the system components need. While usable in its own right, it need not provide maximum performance, or even maximum usability (although good usability will undoubtedly hasten adoption). Built under a public license, it must also be freely-available so it can be used as the basis for augmented implementations.
The initial reference implementation encompasses the advice-giving and advice-receiving apps, along with the information-interchange standards. The subsequent implementation includes the advice-storage server implementation, along with the information-sharing standards.
The effort required to build that system can be broken down into several distinct spheres of activity:
Voting Advice Clients
One or more of:
- A mobile app that lets a voter get advice right at the polls.
- A desktop app that lets a voter get advice, make their selections, and print out a voting “cheat sheet”.
Voting Advice Providers
One or more ways to select a ballot item from the universe of existing tags, and make a recommendation:
- A WordPress plugin.
- A desktop app.
Voting Advice Interchange Standards
This part of the organization manages and publishes the standards that allow advice providers to reach advice clients, and vice versa. Responsible for the definition of the RSS interchange definitions, and for the overall format of the voting advice hashtags, which allows people in Louisiana, for example to create tags with fear of conflict with tags created anywhere else in the nation. This critical part of the effort makes it possible for other client programs and provider programs to be created, with different interfaces and user styles, all of which will tend to hasten adoption.
Voting Advice Tags
While many client and provider programs can and should be created, the hash tags used to deliver voting advice need to be set by a single organization. That organization can be distributed, however. There can be a national organization and an organization in each state, for example. Larger states may then have sub-organizations of their own, each responsible for given districts. Within the namespace carved out for them by the hashtag-definition standard, each organization is free to define tags that make sense for their voters. The resulting definitions then need to be delivered to and stored by the main organization — which will eventually split into two, one for the nation and as a global international organization that coordinates defintions from different countries.
Voting Advice Storage Server
To keep the development effort manageable, the storage server can be implemented in two phases:
- The initial implementation (simpler)
- The reference implementation (complete)
Initial Implementation (Stage 1)
This server stores the hashtags that are used to coordinate advice. Those hashtags are then made available to client and provider programs. In addition, advice pushed by a provider program, may need to be stored on the server, so it that all advice is available to late-adopting voter.
If recommendations are stored by provider programs, and clients can get “all advice from a given date”, then the server doesn’t need to store advice given providers. In that case, the server stores the hash tags that allow for interchange, and provides descriptions for them. This implementation might also respond to requests for lists tags — for example, all tags for a given state, or all applicable tags for a given address and zip code.
On the other hand, if recommendations act more like RSS feeds with more “transient” postings, the server storage will be necessary.
Reference Implementation (Stage 2)
At the outset, the storage server is not part of the reference implementation. To be effective, the system needs to ensure that all advice is available to all users. The most efficient way to accomplish that goal at the start is to have a single server where information is stored.
But the system eventually needs to be fully distributed, just like the web, so there is no single point of failure, which means the system can’t be taken down by a single event, whether natural or intentional. In Stage 2, then, the storage server becomes a reference implementation that works like DNS servers, which propagate their information to one another.
In this implementation, requests for tags might well be coordinated among specialized servers, where each server handles the tags for one or more states. In California, for example, the street address and zip code are sufficient to identify all of the tags used in an upcoming ballot (as demonstrated by the Smart Voter site, sponsored by the League of Women Voters). But if it were the case that not all states follow that rule, then remote server run by the part of the organization that manages hash tags in that area.
Copyright © 2017, TreeLight PenWorks