#1499 and #1500 — filed¶
Filed: 2026-08-08. The last two of the four upstream items from the reporting session; the other two were comments on #789 and #1432.
| # | Title | Backing |
|---|---|---|
| #1499 | Export the voter roll as CSV (smallest slice of #789 — frontend only, data already on the response) | reporting-and-voter-status-map.md |
| #1500 | Epic: reporting & stats — an index of the 88 open report/export issues (no new asks) | report-catalogue.md |
#1499 — voter roll CSV export¶
The one genuinely unfiled gap found in the whole sweep. Argued on size rather than desirability: getRollsByElectionID already returns every voter's email_events in the single call the roll page makes (:125, :152), so delivery status is already in the client's hands and only reachable one voter at a time. Frontend only — no backend, no schema, no new endpoint — with BallotDataExport.tsx's triggerDownload + RFC-4180 csvField there to copy.
Proposed nine columns straight off the response, and named the two constraints an implementer would otherwise hit: voter_id is deliberately absent under email invitation (so the export keys on email), and the button shouldn't render at all in the four open_* modes since :108 throws there. Delivery columns are only meaningful under closed_bv_managed_ids, so they should be omitted rather than shown blank elsewhere.
Offered a PR. Marked the column list as a proposal, since it's read from source rather than run.
#1500 — the epic¶
Filed with the "this is not a new feature request" disclaimer as the first line, because the obvious objection is that it's issue #89 of 88. It asks for nothing unfiled; the value is the index.
Structure: Family 0 (settings decide which reports exist) → five families → the tie decomposition → the scenario matrix → a suggested order. Every issue number was verified open with its real title before publishing; 28 cross-references, all checked. Points at the fuller catalogue rather than duplicating it.
Two things deliberately included that aren't asks: - The Family 0 availability matrix, because #789 reads as universal and isn't. - The open question blocking #763 — if an invitation hard-bounces, was that person eligible? Turnout %, the quorum denominator, and election validity all move with the answer, and BV has no position on it because it has no quorum concept.
Closed by offering to withdraw it if a tracking issue isn't a useful shape for the project — the mapping doesn't have to live in an issue.
Tone note¶
Both say plainly that a good share of the 88 are Adam's own, so the epic reads as tidying up rather than as a demand on maintainers. Worth keeping if either is revised.