osvtac / osv-results-reporter Goto Github PK

You can't tell which language is currently selected; we should style it differently

isWriteIn boolean field or something

Thanks to #16, we now have contest.success for measures, which indicates whether the measure passed or failed. We could indicate this with a green check / red X, or some other visual indication.

"Result stats" (the number of registered voters, total ballots, undervotes, overvotes, etc) are currently only recorded for the overall contest. For RCV contests, some of these stats change from round to round, and should be recorded separately for each round. Specifically, we need the number of continuing ballots, the number of exhausted ballots, and the number of ballots "exhausted" by overvotes.

So that you can run something like ./orr.sh -v --input foo --output bar etc... and have that build the Docker container (if necessary) and run ORR through docker using the given parameters.

For contests that can pass or fail and have a vote threshold (measures, retentions, recalls), we should:

• Print something like "This measure requires 50%+1 affirmative votes to pass" (or 55%, or 66⅔%) above/below the measure
• Draw the dotted line at the threshold

Thanks to #16 this data is now available

The contest-status.json has result_stats RSEli:Eligible Voters currently only provided in the turnout section. It needs to be added to the template.

Add a command-line flag to skip PDF generation. This is because PDF generation can take a while when lots of data is present.

Add an election attribute that gives a title for the report, e.g. Preliminary Report 12.
Also add report time.

It's always 0

Now that we have the TSV files, we can use JavaScript to build a much nicer UI for the detailed results page than the giant table we have there right now. We could let the user select a precinct/neighborhood/district, and see the results for that area.

Requires OSVTAC/osv-sample-data#1

The data added in #16 includes contest.runoff_date and contest.runoff_type. Display this information above/below contests where applicable.

Spotted by @cjerdonek. Note the ’ in the text.

What's probably happening is that this text is double-escaped somewhere, or that it's already HTML with entities in election.json

Some ballot measures require 50%, some require 2/3

Because "no" doesn't have a meaningful bar to clear. Suggested by @cjerdonek

Similar to #4, but for pre-final rounds of a ranked-choice contest. San Francisco's current results reporting highlights the candidate that's leading in each RCV round, even if they don't end up being the overall winner.

The contest.approval_required exists for yes/no votes (measures, recall, retention) and is a printable string, e.g. "{contest.approval_required} Approval Required" is meaningful. [I would advocate simpler representations rather than 50%+1 and long message.] Values are "Majority", \d/\d or \d+%.

In order to draw a threshold line, a property or filter, e.g. approval_required_fraction, should return a numeric value, e.g. .5, .55, .666666666667 so the threshold line can be drawn.

Note for a conditional runoff, there is a 50% threshold (e.g. Superior Court judges), if a candidate gets >50%, then there is no runoff. There is one city in CA that has a conditional runoff for city council with vote for more than 1. In that case, candidates that get >50% of ballots cast are elected, any remaining under 50%, the top n+1 advance to the runoff, where n is remaining seats to be filled. The detailed winning status has this info for all choices.

There is lots of unnecessary whitespace in the generated html, making file storage and transfer inefficient. The templates should use {%- instead of {% to remove whitespace used for template readability. The trim_blocks and lstrip_blocks options can also be enabled.

Right now we draw the dotted line for every contest, whether or not it makes sense to draw it, and always at 50%. For contests where no choice got 50%, we draw the dotted line outside the table, and then hide it with CSS (overflow: hidden).

Instead, we should only draw the dotted line for:

• Yes/no contests (measures, retentions, recalls), and draw it at the approval threshold (see also #19).
• Single-winner RCV contests (the winner's final round percentage will always be >50%)
• Maybe also for single-winner two-choice contests? (E.g. general elections after a top-2 primary)

The data model used by the detailed reports page (templates/test-minimal/extra/results-detail.html) does not distinguish between "real" choices (e.g. candidates or yes/no) and result stats (e.g. undervotes, overvotes). To make this page look better, the template will have to know the difference.

Use symbolic names in the templates, and have files for each language that map those symbolic names for text. English would be just another translation language.

Part of David Cary's suggestions for RCV results reporting format

Right now, the data model doesn't indicate whether a candidate is a winner. This can't be computed (easily) from the vote totals, because some elections have multiple winners (e.g. school board), and some ballot measures require more than 50% (e.g. special tax measures require 2/3). Whether a candidate has won should be an attribute in the input data of the results reporter.

The data model used by the detailed reports page (templates/test-minimal/extra/results-detail.html) breaks down vote totals by precinct, neighborhood and district, but it doesn't distinguish between these things. At the very least, it should distinguish between individual precincts and aggregations thereof, and ideally it would further distinguish different types of aggregations (supe districts, asm/sen/cong districts, neighborhoods, "all")

Thanks to #16, we now have choice.is_writein. We could style these differently, or add "(write-in)", or something.

Need to adjust the color code for the check circle in results match the bar graph.

We already generate an HTML table for every contest with per-precinct vote totals. We could export these tables as JSON/CSV/TSV. It would also be nice to have rotated versions of this: a table for each precinct with per-contest totals.

Chris points out that the entire vote total matrix wouldn't be that large (~2MB), so we could also generate a single file that has every vote total for every candidate/choice for every contest in every precinct.

contest.no_voter_precincts (added by #16) is a list of precinct IDs that have no registered voters. Figure out where we might want to use this information, and use it. We could hide these in per-precinct result tables, for example.

Make the contest names stand out more in the summary page. Attached is what it currently looks like.