Unify ordering of contests

[ion-oset]

Changes to allow generated ballots to be rendered both in the same order on the test cases and in keeping with common conventions on contest order.

(Edit: Removing any reference BallotLab milestones, in keeping with the decision made in the comments)

• Move candidate contests before ballot measure contests.
• Put candidate contests in this order (starting at federal level moving toward the local level)
  • Presidential
  • County school board
  • Mayor of Orbit City
    (This is inferred from the heuristic cited below about "sub-county municipal" before "sub-county non-municipal".)
  • Spaceport board
• Put write-ins after candidates

Context from @trustthevote:

There is some logic for doing all the contests for office before the question
...
For offices ... well President/Vice-President clearly should be first, and county school board before spaceport board, but why mayor last? Not saying it is wrong. But the usual order is: federal, state, multi-county (never mind that for now), county, sub-county municipal, sub-county other-than-municipal.

[trustthevote]

it is not a requirement for this milestone to change the contest order

We do need to capture for later iterations the requirement that EDF-producers follow some ordering rules.

As the EDF is now, the ordering is OK. We might tinker later, but anything non essential we can defer

[trustthevote]

Write-ins of course are required on the ballots.

I am not sure whether the VP office ID is necessary to generate this ballot properly, I will defer to others on that.

[cwulfman]

The OfficeIds for the Presidential race should include the VP office

This should be a separate issue; created #63

[cwulfman]

Changing the order of contests in a BallotStyle isn't difficult; just cut and paste in the JSON file, and drag-and-drop in Versasim. Before we start fiddling and twiddling, though (and issue #62 falls into the same category), I'd like to have a plan: do you want a new test case (for September, if you're collecting these chronologically) that addresses #60, #61, and #62, as well as TrustTheVote-Project/BallotLab#86?

[stratofax]

@ion-oset @cwulfman this is to confirm that a new EDF with re-ordered contests is not required, or even desired, for the current BallotLab milestone, 1. Generate flat PDFs from Jetsons EDF Milestone, as noted by @trustthevote.

I did request an updated EDF with human-readable IDs to support Write Contest IDs on ballot for testing and review · Issue #86, which I've currently added to the new BallotLab milestone, 3. Pagination, page breaks, and page count Milestone. From my perspective this third milestone would also be a good time to re-order the contests and candidates. In other words, this is not a pressing requirement for my work on BallotLab, either for this week or next.

Thus, I also agree with the previous comment (by @cwulfman), that we should first have a clear plan for this new EDF test case to address the appropriate issues in this repo, before fiddling & twiddling.

[ion-oset]

@stratofax:

This is to confirm that a new EDF with re-ordered contests is not required, or even desired, for the current BallotLab milestone,

Confirmed 👍🏼. I've updated the issue description accordingly to remove any reference to a particular BallotLab milestone. We can re-reference when we get to milestone 3.

[ion-oset]

@cwulfman

Do you want a new test case (for September, if you're collecting these chronologically) that addresses #60, #61, and #62, as well as TrustTheVote-Project/BallotLab#86

I'm not clear on what the threshold is for making a new test case for the month so whether or not this a new test case or just an update of an old one I defer to you on. I will note that the total number of changes is small. I can easily see one PR fixing #61 and #63 at once. Even #62, at least as it relates to BallotLab's specific needs, is not much work presuming we aren't worried about getting a completely vetted naming scheme in place - it took me about 20 minutes to do it for my own testing.

[ion-oset]

Hmm. Let me answer your question more explicitly. I propose:

• I propose one PR (e.g. "Changes need for BallotLab") that fixes all of:
  • Create EDF test cases of Ranked Choice Voting #60
  • Unify ordering of contests #61
  • Use human-readable identifiers for EDF and CVR elements #62
    (The BallotLab specific part, not the entire naming scheme issue)
  • The OfficeIds for the Presidential race should include the VP office #63
• Each issue is addressed by an individual commit.
• That PR is tentatively targeted for BallotLab milestone #3 per @stratofax's explanation.

Amend as you see fit.

[cwulfman]

I think this is overkill, @ion-oset . I addressed #63 and closed the issue in less than 5 minutes; using human-readable identifiers in EDF and CVR elements (#62) will require consensus on what those ids should look like and some development work on Versasim (which is not actually part of TTV); @stratofax has said he doesn't want us to do #61; #60 is an independent task @trustthevote has mentioned as something for "phase 3" (undefined so far).

[ion-oset]

@cwulfman Fine with me. I was offering a plan per your request, but as far I'm concerned it should happen in the order you see fit.

FWIW though I don't think what I suggested is overkill. It certainly isn't meant to be: my whole point is that most this isn't a lot of work. #61 and the BallotLab specific part of #62 are less than an hour of work (at least the way I did them for my testing). I agree that the full #62 is more complex, so if we don't want have something incomplete land just for BallotLab testing, we shouldn't include it. I defer to you on #60. You mentioned it so I misunderstood that to mean you were seeing as part of the set.

@stratofax has said he doesn't want us to do #61

Hmm. I'm not sure. I read what he said as "defer this to BallotLab milestone 3":

From my perspective this third milestone would also be a good time to re-order the contests and candidates.

Neil?

[stratofax]

@cwulfman @ion-oset I did mean 100% that I want to defer #61 for a week or two, not to drop it.