Ms. Voting Matters here, and I'm going to start spending more time sharing things with our readers here who couldn't care less about code (although it does cause change ;) but who, like myself, really care a bunch more about how we preserve our right to be a part of our democracy. And for us, that means more easily and conveniently casting our ballot and knowing our ballots are counted as cast, right? So for you, my thought today is about something that makes total sense on the one hand, and totally doesn't on the other... the voter selfie. I went back and forth on this for days, reading various views from Vogue to the NY Times, and here is where I come down on this. I hope you'll think about it, and reach a similar conclusion...
Viewing entries in
Elections data standards are essential to delivering real innovation. The annual Election Data Standards meeting opened today in Los Angeles, CA. We thought we'd give you an overview of just what in the hec this is about and why its essential to creating a voting experience that's easy, convenient, and dare we say delightful. Dry? Kinda. But a peek at the real in the trenches work we're doing. Yep.
The TrustTheVote Project Core Team has been hard at work on the Alpha version ofVoteStream, our election results reporting technology. They recently wrapped up a prototype phase funded by the Knight Foundation, and then forged ahead a bit, to incorporate data from additional counties, provided by by participating state or local election officials after the official wrap-up.
Along the way, there have been a series of postings here that together tell a story about the VoteStream prototype project. They start with a basic description of the project in Towards Standardized Election Results Data Reporting and Election Results Reload: the Time is Right. Then there was a series of posts about the project’s assumptions about data, about software (part one and part two), and about standards and converters (part one and part two).
Of course, the information wouldn’t be complete without a description of the open-source software prototype itself, provided Not Just Election Night: VoteStream.
Actually the project was as much about data, standards, and tools, as software. On the data front, there is a general introduction to a major part of the project’s work in “data wrangling” in VoteStream: Data-Wrangling of Election Results Data. After that were more posts on data wrangling, quite deep in the data-head shed — but still important, because each one is about the work required to take real election data and real election result data from disparate counties across the country, and fit into a common data format and common online user experience. The deep data-heads can find quite a bit of detail in three postings about data wrangling, in Ramsey County MN, in Travis County TX, and in Los Angeles CountyCA.
Today, there is a VoteStream project web site with VoteStream itself and the latest set of multi-county election results, but also with some additional explanatory material, including the election results data for each of these counties. Of course, you can get that from the VoteStream API or data feed, but there may be some interest in the actual source data. For more on those developments, stay tuned!
If you've read some of the ongoing thread about our VoteStream effort, it's been a lot about data and standards. Today is more of the same, but first with a nod that the software development is going fine, as well. We've come up with a preliminary data model, gotten real results data from Ramsey County, Minnesota, and developed most of the key features in the VoteStream prototype, using the TrustTheVote Project's Election Results Reporting Platform. I'll have plenty to say about the data-wrangling as we move through several different counties' data. But today I want to focus on a key structuring principle that works both for data and for the work that real local election officials (LEOS) do, before an election, during election night, and thereafter.
Put simply, the basic structuring principle is that the election definition comes first, and the election results come later and refer to the election definition. This principle matches the work that LEOs do, using their election management system to define each contest in an upcoming election, define each candidate, and do on. The result of that work is a data set that both serves as an election definition, and also provides the context for the election by defining the jurisdiction in which the election will be held. The jurisdiction is typically a set of electoral districts (e.g. a congressional district, or a city council seat), and a county divided into precincts, each of which votes on a specific set of contests in the election.
Our shorthand term for this dataset is JEDI (jurisdiction election data interchange), which is all the data about an election that an independent system would need to know. Most current voting system products have an Election Management System (EMS) product that can produce a JEDI in a proprietary format, for use in reporting, or ballot counting devices. Several states and localities have already adopted the VIP standard for publishing a similar set of information.
We've adopted the VIP format as the standard that that we'll be using on the TrustTheVote Project. And we're developing a few modest extensions to it, that are needed to represent a full JEDI that meets the needs of VoteStream, or really any system that consumes and displays election results. All extensions are optional and backwards compatible, and we'll be submitting them as suggestions, when we think we got a full set. So far, it's pretty basic: the inclusion of geographic data that describes a precinct's boundaries; a use of existing meta-data to note whether a district is a federal, state, or local district.
So far, this is working well, and we expect to be able to construct a VIP-standard JEDI for each county in our VoteStream project, based on the extant source data that we have. The next step, which may be a bit more hairy, is a similar standard for election results with the detailed information that we want to present via VoteStream.
PS: If you want to look at a small artificial JEDI, it's right here: Arden County, a fictional county that has just 3 precincts, about a dozen districts, and Nov/2012 election. It's short enough that you can page through it and get a feel for what kinds of data are required.
It's time to finish -- in two parts -- the long-ish explanation of the assumptions behind our current "VoteStream" prototype stage of the TrustTheVote Project's Election Result Reporting Platform (ENRS) project. As I said before, it is an exercise in validating some key assumptions, and discovering their limits. Previously, I've described our assumptions about election results data, and the software that can present it. Today, I'll explain the 3rd of three basic assumptions, which in a nutshell is this:
- If the data has the characteristics that we assumed, and
- if the software (to present that data) is as feasible and useful as we assumed;
- then there is a method for getting the data from its source to the reporting software, and
- that method is practical for real-world elections organization, scalable, and feasible to be adopted widely.
So, where are we today? Well, as previous postings have described, we made a good start on validating the first 2 assumptions during the previous design phase. And since starting this prototype phase, we've improved the designs and put them into action. So far so good: the data is richer than we assumed; the software is actually significantly more flexible than before, and effectively presents the data. We're pretty confident that our assumptions were valid on those two points.
But where did the 2012 election results data come from, and how did it get into the ENRS prototype? Invented elections, or small transcribed subsets of real results, were fine for design; but in this phase it needs to be real data, complete data, from real election officials, used in a regular and repeated way. That's the kind of connection between data source and ENRS software that we've been assuming.
Having stated this third of three assumptions, the next point is about what we're doing to prove that assumption, and assess it limits. That will be part two of two, of this last segment of my account of our assumptions and progress to date.
Now that we are a ways into our "Election Night Reporting System" project, we want to start sharing some of what we are learning. We had talked about a dedicated Wiki or some such, but our time was better spent digging into the assignment graciously supported by the Knight Foundation Prototype Fund. Perhaps the best place to start is a summary of what we've been saying within the ENRS team, about what we're trying to accomplish. First, we're toying with this silly internal project code name, "ENRS" and we don't expect it to hang around forever. Our biggest grip is that what we're trying to do extends way beyond the night of elections, but more about that later.
Our ENRS project is based on a few assumptions, or perhaps one could say some hypotheses that we hope to prove. "Prove" is probably a strong word. It might better to say that we expect that our assumptions will be valid, but with practical limitations that we'll discover.
The assumptions are fundamentally about three related topics:
- The nature and detail of election results data;
- The types of software and services that one could build to leverage that data for public transparency; and
- Perhaps most critically, the ability for data and software to interact in a standard way that could be adopted broadly.
As we go along in the project, we hope to say more about the assumptions in each of these areas.
But it is the goal of feasible broad adoption of standards that is really the most important part. There's a huge amount of latent value (in terms of transparency and accountability) to be had from aggregating and analyzing a huge amount of election results data. But most of that data is effectively locked up, at present, in thousands of little lockboxes of proprietary and/or legacy data formats.
It's not as though most local election officials -- the folks who are the source of election results data, as they conduct elections and the process of tallying ballots -- want to keep the data locked up, nor to impede others' activities in aggregating results data across counties and states, and analyzing it. Rather, most local election officials just don't have the means to "get the data out" in way that supports such activities.
We believe that the time is right to create the technology to do just that, and enable election officials to use the technology quickly and easily. And this prototype phase of ENRS is the beginning.
Lastly, we have many people to thank, starting with Chris Barr and the Knight Foundation for its grant to support this prototype project. Further, the current work is based on a previous design phase. Our thanks to our interactive design team led by DDO, and the Travis County, TX Elections Team who provided valuable input and feedback during that earlier phase of work, without which the current project wouldn't be possible.
Long lines at the polling place are becoming a thorn in our democracy. We realized a few months ago that our elections technology framework data layer could provide information that when combined with community-based information gathering might lessen the discomfort of that thorn. Actually, that realization happened while hearing friends extol the virtues of Waze. Simply enough, the idea was crowd-sourcing wait information to at least gain some insight on how busy a polling place might be at the time one wants to go cast their ballot.
Well, to be sure, lots of people are noodling around lots of good ideas and there is certainly no shortage of discussion on the topic of polling place performance. And, we’re all aware that the President has taken issue with it and after a couple of mentions in speeches, created the Bauer-Ginsberg Commission. So, it seems reasonable to assume this idea of engaging some self-reporting isn’t entirely novel.
After all, its kewl to imagine being able to tell – in real time – what the current wait time at the polling place is, so a voter can avoid the crowds, or a news organization can track the hot spots of long lines. We do some "ideating" below but first I offer three observations from our noodling:
- It really is a good idea; but
- There’s a large lemon in it; yet
- We have the recipe for some decent lemonade.
Here’s the Ideation Part
Wouldn’t it be great if everybody could use an app on their smarty phone to say, “Hi All, its me, I just arrived at my polling place, the line looks a bit long.” and then later, “Me again, OK, just finished voting, and geesh, like 90 minutes from start to finish… not so good,” or “Me again, I’m bailing. Need to get to airport.”
And wouldn’t it be great if all that input from every voter was gathered in the cloud somehow, so I could look-up my polling place, see the wait time, the trend line of wait times, the percentage of my precinct’s non-absentee voters who already voted, and other helpful stuff? And wouldn’t it be interesting if the news media could show a real time view across a whole county or State?
Well, if you’re reading this, I bet you agree, “Yes, yes it would." Sure. Except for one thing. To be really useful it would have to be accurate. And if there is a question about accuracy (ah shoot, ya know where this is going, don-cha?) Yes, there is always that Grinch called “abuse.”
Sigh. We know from recent big elections that apparently, partisan organizations are sometimes willing to spend lots of money on billboard ads, spam campaigns, robo-calls, and so on, to actually try to discourage people from going to the polls, within targeted locales and/or demographics. So, we could expect this great idea, in some cases, to fall afoul of similar abuse. And that’s the fat lemon.
But, please read on.
Now, we can imagine some frequent readers spinning up to accuse us of wanting everything to be perfectly secure, of letting the best be the enemy of the good, and noting that nothing will ever be accomplished if first every objection must be overcome. On other days, they might be right, but not so much today.
We don’t believe this polling place traffic monitoring service idea requires the invention of some new security, or integrity, or privacy stuff. On the other hand, relying on the honor system is probably not right either. Instead, we think that in real life something like this would have a much better chance of launch and sustained benefit, if it were based on some existing model of voters doing mobile computing in responsible way that’s not trivial to abuse like the honor system.
And that lead us to the good news – you see, we have such an existing model, in real life. That’s the new ingredient, along with that lemon above, and a little innovative sugar, for the lemonade that I mentioned.
Stay tuned for Part 2, and while waiting you might glance at this.
NYT reported on the continuing counting in some New York elections, with the control of the NY state house (and hence redistricting) hanging in the balance. The article is mostly apt, but the reference to "hanging chad" is not quite right. FL 2000's hanging chad drama was mainly about the ridiculous extreme that FL went to in trying to regularize the hand re-counting rules for paper ballots, while each time a ballot was touched, the rule could change because the chad moved. In this NY election, the problem is not a re-count, but a slow count; not problems with the paper ballots per se, but with the opscan counting system; and not a fundamental problem with the ballot counting method, but several problems arising from poll-worker and election officials' unfamiliarity with the system, being used for the first time in this election. Best quote:
Reginald A. LaFayette, the Democratic chairman of the Board of Elections in Westchester, said older poll workers had trouble reading the vote tallies printed out by the machines. “You take the average age of an inspector, it’s maybe about 65, and so you put a new product out with them, and the change has been overwhelming to some of them,” he said.
It's another example of the of situation I recently described in North Carolina. These voting systems were built for time-to-market, rather than designed, engineered, and tested for usability and reliability -- much less designed for simplicity of the process of combining tallies into election results.
The recent experience in New York is nothing truly new - but rather an example of the usability issues manifested in an election organization that, unlike those elsewhere using similar voting system products, has not yet learned by experience how to use these quirky systems with greater speed and transparency than the first time around. Of course, it is a shame that this type learning-by-doing in real elections is necessary at all, to get to a reasonably transparent election process. But that's what the vendors served up the market, and that's what TTV is working to improve on.
Whew. We're through it, and for all the angst, sweat, and tears, I sense it went well. I want to thank the Panelists for being so good-natured (and well behaved as to the time limits in responses). We had some intense moments of heated disagreement and heated agreement. I'll have some more to say later when more recovered, but I believe this is the start of an on-going conversation that brought out the challenges and opportunities of using the Internet in the elections and voting processes.
- Apologies to Operation Bravo for getting it absolutely wrong on the Pilot locations (polling being on verses off Military base). I learned a valuable lesson to not try and wedge in that final question in the middle of the night when its too late to wake anyone to confirm facts. Good thing I had the "Plan B" question.
- Apologies to the activists who hounded me about using a coin toss to determine which side went first on closing remarks. I agreed to do so, put the 2 Euro in my pocket to toss, and then completely forgot in the rush of the final moments before going live to actually toss the coin, and had to randomly point at one side to go first at closing. DoH!
For whatever its worth, I will not declare a winner or loser. You can watch it on Vimeo or YouTube yourself when it finally posts in a couple of weeks.
But I will say this, as Moderator I thought the Proponents Team pulled it together in the closing argument and made some interesting points after earlier seemingly dropping some balls on answers. And I thought the Opponents Team could've registered a far stronger closing statement after slicing through issues with surgical precision throughout the preceding 80 minutes.
One More Apology
One final, off-topic comment that constitutes another, more serious "mea culpa." It has been called to my attention by a County Elections Official from Ohio who was "in the trenches" in 2004 and 2006, that our Every Vote Counts booklet has an error on the time-line page claiming a recount was required in the 2004 Ohio results due to machine errors. This is completely false on all counts and I allowed ourselves to be drawn in by some faulty reporting and research. In fact, some recounts in 2006 (not '04) were due to some scanning equipment malfunctions of a mechanical nature only. The machine issues otherwise alleged have never been substantiated and this Election Official, Rokey Suleman (now running elections in D.C.) has good reason to be frustrated with me by something unintentionally picking at an old battle scar.
We're going to fix that. I am committed to transparency. First, may I please publicly apologize to Rokey Suleman for my public relations and outreach teams' embarrassing goof. The buck (er, book) stops with me; they're my team and I take full responsibility for that. There are no excuses. We should have done closer proofing of the work. OSDV Foundation has a great story to tell, and I hate the possibility of diluting it with an errant statement or representation.
Here is the repair list:
- We will correct that page before any further printing of that booklet. I will do my best to halt further distribution of this version, but apologize in advance if there remain copies floating about or accidentally further distributed.
- More importantly, we're going to give Rokey Suleman our podium here to explain to all of you reading, the story inside Ohio from one of the gentleman who was in the middle of it; from his personal and direct experience. Mr. Suleman has agreed to draft that for our publication here under his name as a guest blogger.
Furthermore, I note that we learned here in Munich that Rokey is doing some amazing things in his new appointment running D.C. elections. And he has a deep commitment to overseas and military voters. I find him to be highly motivated, and passionately committed to accurate, transparent, trustworthy, and secure elections. And I am impressed by his innovative attitude and intense commitment to seeing the District of Columbia (America's answer to the Vatican ;-) ) be a thought leader and model for elections in the 21st century and digital age. His passion for transparency (and interest in open source methods) is refreshing.
I hope this small token of our regrets will allow Rokey Suleman another reasonably public forum to set the record straight (in this case, apparently skewed again at our own hands).
Otherwise, the Debate was fun and exhausting and I can't wait for the video replay. Cheers
I came across an interesting article about voter registration: "The Alternative to Universal Voter Registration" where John N. Hall strongly supports Automatic Registration (AR) over Universal Voter Registration (UVR). To people who are not election experts the distinction is a bit subtle. UVR has states proactively try to register everyone to vote, while AR has the federal government somehow use Social Security records to automatically register people.
In Mr Hall's words, AR can be implemented by doing the following:
"Computer programs read through the Social Security Administration database, extract the data of age-eligible citizens, then send that data to the states." (from The Alternative To Universal Voter Registration)
Now that I started writing this post and did some more googling I see that this is already a heavily debated topic that has flown back and forth, starting with John Fund's (of the Wall Street Journal) original talk, to Rep. Barney Frank's angry denunciation that he had nothing to do with the claims that he was involved in any way with Universal Voter Registration, to Mr Fund's retraction of the claim, to more links than you can shake as stick at about the topic.
Anyway as usual I am johnny come lately. Phew. My original thought though was about the original post. You see, John Hall, being a "computer programmer" makes it sounds simple:
"Voila! Why make mandates on all those state agencies and dragoon all that manpower entailed by UVR when a computer program can register everyone? A competent programmer could write the extract program in his sleep." (from The Alternative to Universal Voter Registration)
Any description of this that starts with "Voila" and ends with "in his sleep" is ... well let's just say, it must be a bit of a simplification....
For example I would imagine that there would be major privacy concerns about sending information out of the social security systems out to each of the states. I am not sure that the states registration records even include social security information. And what about all the voters who don't have social security numbers, there must be some, or many? And how quickly are the social security databases updated when people die?
The TrustTheVote Project issued its first formal "Call For Participation" ("CFP") to its Stakeholder Community last evening, and five elections jurisdiction have already indicated interest. The CFP is inviting collaboration from elections jurisdictions all over the country who need to determine how to comply with the mandates of the new federal MOVE Act -- particularly the requirement to provide a digital (online) means to deliver a download-ready blank ballot for any overseas voter wishing to participate in an election in their jurisdiction, and particularly one that has any federal contest included.
The TrustTheVote Project has developed a sufficient amount of its overall elections systems framework to be able to deliver a solution today for this requirement (pending any adjustments, modifications, or "tweaking" required to meet local requirements.)
Really, this is a big deal. You see, digitally serving anyone the official ballot for their district of residence is deceptively simple. In fact, its non-trivial. And yet, every jurisdiction where there are permanent residents stationed overseas either in the military or in some other NGO including simply an employer assignment needs to (and by federal law must) be able to cast an absentee ballot. But how to get the ballot to them in time for them to prepare it and return to be counted? We first presented a solution for this in a White Paper in December 2009.
To back up a bit, the MOVE Act was signed into law in November by the President, and essentially is intended to update and bring into the 21st century digital society the UOCAVA law from decades ago. For readers unfamiliar with these terms, here's a quick tutorial.
In 1986, Congress passed the Uniformed and Overseas Citizens Absentee Voting Act ("UOCAVA"). The UOCAVA requires that the states and territories allow certain groups of citizens to register and vote absentee in elections for Federal offices. In addition, most states and territories have their own laws allowing citizens covered by the UOCAVA to register and vote absentee in state and local elections as well. United States citizens covered by the UOCAVA include: members of the United States Uniformed Services and merchant marine; their family members; and United States citizens residing outside the United States.
After the 2008 elections cycle it was determined that up to 1 in 4 military and overseas voters were disenfranchised because they didn't receive their ballots in time. In the autumn of 2009, Congress passed the new Military and Overseas Voter Empowerment (MOVE) Act, which is a complement and update to UOCAVA. Among other provisions, the MOVE Act mandates that States shall provide a digital (online) means for a UOCAVA voter to manage their voter registration status and to receive a download ready blank ballot for the elections jurisdiction of their registered permanent residence.
Of course, there are those out there who shrill at the prospect that somehow, someway this could lead to Internet voting. Very unlikely, and please don't get me started down that rat hole either. Let me stay trained on the important point here.
The work of the TrustTheVote Project, to bring innovative open source digital voting technology to the public, already addresses the mandates of the MOVE Act. And we've reached a point where issuing the CFP just makes sense to enlarge the pool of jurisidictions testing and evaluating our solution, and positioning themselves to acquire the tools when they are ready.
And of course, the really nice part: the software tools are free -- that's the benevolent point of the Open Source Digital Voting Foundation and the TrustTheVote Project. Yes, we appreciate and encourage donations to the Foundation to defray the development costs (particularly if a jurisdiction desires the assistance of our technology development team to tailor the software to their exacting requirements), but the source code is free and will be theirs to do with as they wish (especially for software that does not require certification for voting systems purposes.)
Interested? Great! Get started by downloading the CFP here. And get in touch with us.
Yeah this is old hat to election-insiders (I am not yet one, so I can still have that sense of wonder :) but I just took a drive through the "Voting Information Project" web site. I think it's a cool idea that could be a template to catalyze very useful election related information resources in a totally decentralized manner, where each state or locality can elect when and how to join in. In case you haven't heard about it, this is from their site:
"...As a fundamental step in this initiative, the Voting Information Project is partnering with a group of state election officials to develop and implement a technical standard, known as an "open format," by which state and local election officials can more efficiently disseminate voting information. " (from Voting Information Project)
If a state chooses to provide election related information in this format, at a known URL, this information will be pulled into the VIP system and in turn be deliverable to web sites, cell phones, twitter, facebook, yadi yada.
In other words, the one fairly simple piece of work is leveraged multiple times and brought to where it can be used by voters. Pretty cool, and maybe a template for decentralized adoption and deployment of election info services of other kinds in the future.
Here's the FAQ of the Voter Information Project.