Ticket selections require candidate or office count

[stratofax]

For two candidate (or two office) tickets, as specified in the EAC documents, instruct voters as follows: "Vote for 1 pair". Also, increase the number of lines in write-in slots From 1 to 2.

Is there an existing data element in the EDF we can use to track this explicitly?

[stratofax]

@ion-oset The best way to implement this feature is to count the number of OfficeIds. Correct OfficeIds would also allow the contest title to read "President and Vice President" -- but this raises some other issues around the EDF, which I'll record elsewhere.

[stratofax]

@trustthevote @ion-oset @cwulfman

This feature turns out to be a little more complicated than anticipated, perhaps because there's not (as of yet) any specific data element in the EDF that I can point to and say, "this ticket requires two candidate names."

Right now, the Prez/VP ticket lists two names for each candidate, but there's nothing in the EDF that says there has to be two names on the ticket -- unless I'm missing something.

Anyway, I'm pushing everything that involves a potential update to the EDF to 3. Pagination, page breaks, and page count Milestone.

Perhaps we can open a discussion on this issue on ElectOS-Dev · The TrustTheVote® Project Discussions -- is this the preferred location for cross-repo discussions?

[ion-oset]

I believe the answer is the one you already have: use CandidateContest.OfficeIds (SP 1500-100 r2, sec. 5.8, p. 33) as the requirement. That field exists to connect candidates to offices.

If the candidate contest is associated with a ticket (of candidates) and each candidate in the ticket is associated with a separate office, the association to Office can reference each of the separate offices.

Candidates in a contest have to fill those offices - no more, and no less. I think it's correct to say that list authoritative on what the offices are and what order they should appear in. (This is why we've discussed adding OfficeIds to the BallotLab data subset, and why we decided to create NIST 1500 test cases #63.)

The one caveat is that this clearly applies only to contests where VotesAllowed is 1 (so at least the VoteVariations plurality & majority). I'm not sure how offices map to candidates in RCV - only that there must be a mapping, because there are still those number of seats to fill.

[cwulfman]

I don't have time to address this right now, but I believe @ion-oset is incorrect here. The operative values are VotesAllowed, CandidateContest, and CandidateSelection. You should not need to know anything about the office.

[stratofax]

I find that writing this stuff out is very helpful. My current thinking is that I could implement extra layout features if additional data is available in the EDF. So I agree with both of you:

• The @ion-oset scenario (above) makes sense as a way to unlock certain "deluxe" layout features, like more detailed contest instructions ("Vote for 1 pair" instead of the default "Vote for 1", for example). I notice that the quote from the spec says "Office can reference each of the separate offices" instead of "Office must reference ...", supporting the idea of using this data element conditionally.
• @cwulfman is correct, the data in VotesAllowed, CandidateContest, and CandidateSelection is sufficient to lay out the ballots -- but it would be nice to know for sure how many offices are part of a Vote for 1 ticket. This can be provided by OfficeIds.

[ion-oset]

Hmm. I went back and looked CandidateContest again and there is one field that might be a better fit for the authoritative list of how many candidates are allowed in a selection: NumberElected.

This is defined as

Number of candidates that are elected in the contest

and later:

the number of seats associated with the office

That seems like it fits? I am a little uncertain if the field description is somehow limiting it to n-of-m contests, and because it's optional - what value is used if it's missing? 1 makes sense but I don't see any requirement.

[stratofax]

Great research! Another area where this value is significant is the size of the write-in block; e.g., a two-candidate ticket really needs a two-line write in option. This is currently not addressed in the sample ballot, so I'm going to re-write this issue to include the write-in aspect.

[cwulfman]

I'm busily writing up a set of guidelines for you, @stratofax , but the short answer is that you should count the ContestSelections.

[stratofax]

@ion-oset I wanted to check in with you to see if we can resolve this with an entry on ballot_layout_considerations · TrustTheVote-Project/NIST-1500-100-103-examples Wiki