Recall contest representations not defined

[carl3]

Organization Name: Carl Hage

Organization Type: 4

Document: SP1500-100 ElectionResultsReporting

Reference: 4.2.6.1 BallotMeasureContest

Comment: There is no explicit representation for a recall contest. Presumably it could be represented as a BallotMeasureContest with Yes/No vote, but then there is no way to link the contest with an office and incumbent. Likewise there is no way to link the recall contest with replacement candidates, who are elected only if the recall succeeds.

Suggested Change: Add a new <RecallContest> type, a subtype of BallotMeasureContest with some additional elements added:

• <OfficeId> a link to the office in the recall.
• <PersonId> a link to the incumbent being recalled.
• <ReplacementContestId> contest ID for a replacement if the recall succeeds.

[jdmgoogle]

Why wouldn't this work as a RetentionContest?

[carl3]

A RetentionContest almost works, but doesn't allow a way to link to the associated replacement contest.

However, approval voting and recall voting are both well known concepts, so it seems to me adding one word (additional element subclass) to the standard to explicitly represent each is better than shoehorning recalls into measure or approval contest and letting the receiving app try to figure it out. Recalls have very specific presentations, different than approval voting, so don't make the reading app try to figure it out by parsing titles-- just declare it as a recall by the originator.

[jdmgoogle]

@carl3 Could you link to a sample printed ballot (e.g., PNG, PDF, JPG) which shows what the voter sees in a recall contest situation? I found the following sample from the 2003 CA Gubernatorial recount:

https://upload.wikimedia.org/wikipedia/commons/c/c6/Sample_ballot_for_CA_recall.png

That seems to indicate that a "recall contest" is actually two separate measures:

1. A BallotMeasureContest with a Yes/No about should they be replaced
2. A CandidateContest asking who should replace them.

This doesn't feel that much different than when there are, say, conflicting ballot measures and there are rules about which hold sway depending on the vote outcome. Just because behind-the-scenes they're linked together doesn't mean that -- on the ballot, at least -- they're not two separate contests (IMHO).

[carl3]

Yes, recalls are 2 separate (but related) contests with separate results reported, one is a subtype of a measure with question and yes/no answer, the other is a usual candidate contest. A Recall contest type would allow a measure to be linked to the office and incumbent. The person being recalled has an opportunity to make a statement.

Normally the recall question appears with other similar candidate (office) contests. They are usually entered as candidate contest IDs in an EMS (DFM), but sometimes they are entered as a measure.

In most cases recall contests would have a question with text like "Shall {{Candidate_Name}} be recalled (removed) from the office of {{Office_Name_And_District}}?" and the candidate contest has a title like "Candidate to succeed {{Candidate_Name}} as {{Office_Name_And_District}} if {HeShe}} is recalled".

That Gubernatorial recall was an aberration with so many candidates. Here are a couple of usual recall sample ballots:

http://www2.co.fresno.ca.us/2850/post/root0412/ballots/bt000002.pdf http://www2.co.fresno.ca.us/2850/post/2016aprcandidatelist.pdf http://www2.co.fresno.ca.us/2850/Results/Results-2016-04-12.htm

https://www.ocvote.com/fileadmin/user_upload/elections/gen2016/sbs/bt9.pdf

https://clerk-recorder.buttecounty.net/elections/archives/eln36/36_insert_artwork_final.pdf https://clerk-recorder.buttecounty.net/elections/archives/eln36/36_candidate_list.pdf https://clerk-recorder.buttecounty.net/elections/archives/eln36/36_results.pdf

[jdmgoogle]

Yes, recalls are 2 separate (but related) contests with separate results reported

I think that's the answer there, then. Otherwise we get into a morass of trying to encode business logic into a data specification; e.g., it would be infeasible and out-of-scope (IMHO) for 1500-100 to specify the different rules for each of the 17 states that outline what to do with conflicting ballot resolutions.

The recall question perfectly fits the definition of a RetentionContest, and the other as a CandidateContest. The SequenceOrder element of the Contest should ensure that any sample ballots generated from these files group the two contests together.

[carl3]

jdm Could you explain your reluctance to make a small extension to the spec to accomodate proper labelling of recalls? A retention contest (a known usual case) is not the same as a recall (also a known usual case). For one, results are opposite, but the main significance is that recalls have a special process in the election cycle, and maybe special handling in presentation. The target of a recall is not a candidate in the usual sense, whereas a retention candidate is. With a small change to the spec and simple change to an xml writer (or validator), recall can be labelled as is rather than misrepresenting it. Otherwise, every xml reader needs to parse free-form text to determine if a retention contest is really a recall-- all due to a defect in the standard. I think the spec should label the contest type correctly.

[johnpwack]

carl, I've been following the thread and hopefully understand it. The state to state variation relates to the voting rules as to what has to happen on the first contest in order for the voter to be eligible to vote on the second contest. Some require a Yes vote, others require either a Yes or No vote. A California judge I think invalidated the 2 contest approach, indicating that a voter should be able to vote on the second contest no matter what they did on the first contest. I think there are also recalls without the contest pair but they are just treated as normal contests. Thus, I'm in favor of not creating a recall contest type because of the state to state variations, but rather if there are two contests, linking them by ID - I have checked with ESS on this and this is the way they do it, I believe.

[carl3]

Thanks John. I am also suggesting there should be 2 contests with the possibility (not requirement) that there is a linkage between the recall question contest and the replacement contest. The recall contest would be similar to a retention contest (could be a subtype), except it's labelled as a recall type (not labelled as retention) and also has the ability to add an IDREF to the replacement contest. The replacement contest would be a normal candidate contest-- the only difference is that it can be referenced in the (separate) recall contest. [I don't see a reason to link the replacement to the recall question contest-- the reverse is best.] I think this representation is independent of any state laws, though as you mention the interpretation of results could be different. Identifying a contest as a recall with linkage to the replacement contest would allow CVRs to be interpreted correctly, depending on state law.

Technically, the recall question contest would be associated with a personID, but I don't think it matters all that much if it's a candidateID instead, as long as the contest type is labelled as a recall type. [Note there is no pre-election status for a recall target (they aren't a candidate), but post election status could be "recalled" or "retained". [Likewise there is no retained or not retained PostElectionStatus enumeration definition for a retention candidate.]

[johnpwack]

Carl, again I'm opposed to adding this, as I don't think it's necessary - using existing contest types and linking them does the same as what you suggest, and as the model/schema is already complex, I resist adding more to it unless it's really necessary. The schema has had a lot of review from major manufacturers and other election officials, all who deal with recall contests. I've asked John Dziurlaj, another implementer beside Justin, to weigh in on this issue.

[JDziurlaj]

On the question to rename or add another subtype under BallotMeasureContest for the purposes of disambiguation; a new subtype would likely be the best approach, as Carl's right in that those appearing on a RecallContest are not candidates in the strict sense. I don't see this as a problem from an feed producer perspective, but it does increase the complexity from a consumer's perspective.

I would add that these semantics are probably not required if the goal is to report results. If the goal is to model EMSs (i.e. for interoperability between local source EMSs and state EMSs) more broadly, then these semantics would be of more value.

On the question on whether a link should be provided between one contest that is related to another, I would want to see if this is a common scenario (recall question appearing along with potential replacements), as I have never encountered it.

John.

[jdmgoogle]

@JDziurlaj If the goal is, indeed, to model EMSes, then is the implication that there would be no external clients for this data?

The implication is that a RetentionContest (in which voters vote Yes or No on whether to allow a given Candidate to remain in a given Office, with its related Term information) is sufficiently different from a RecallContest (in which voters vote Yes or No on whether to allow a given Candidate to remain in a given Office, with its related Term information) and EMSes are unable to distinguish between the two to the point where the data spec needs to create new UML classes. That criteria -- same data structure, different only in name -- also implies that the data standard should distinguish between the 12 different types of ballot measures in the US by having a unique UML class for each of those 12 types.

Given the choice between (a) implementing support for 15 BallotMeasureContest types (base class, retention, recall, and the 12 subtypes laid out in the ballotpedia article), and (b) simply not supporting ballot measure contests, I'm pretty sure that even we would go with option (b), and many other prospective consumers would do the same.

I'm just trying to understand how a proposed RecallContest is sufficiently unique from "a contest in which voters vote Yes or No on whether to allow a given Candidate to remain in a given Office, with its related Term information" that it deserves its own new object type, and (more importantly) what the implication is for deciding when to create a new UML type.

[carl3]

Adding a "recall" BallotMeasureType with usual BallotMeasureContest would be a usable solution. A separate subtype is only needed to allow an IDREF to the replacement contest-- the IDREF is not meaningful in a RetentionContest. (You only need different elements if the members (fields) are different.) [A RetentionContest is a subtype of BallotMeasureContest and so has the <Type>.] Note with approval voting, a RetentionContest would be used possibly for voter approval of government nominated candidates, not just an incumbent-- so maybe not the best label. Adding "retention" and "approval" could disambiguate, though it probably doesn't make much difference, since interpreting results is the same.

I think the only difference in the BallotMeasureType (e.g. initiative vs referendum) is in the ballot composition for use in inserting a BallotSubTitle. Note I am assuing the CDF related to contest definitions in results would be reused for other data collections, including EMS interoperability, e.g. with candidate filing and ballot layout software. A missing type "advisory-vote" is also relevant to interpreting results as well as BallotSubTitle.

Rather than having a fixed type, I think it is better to have an extensible set of attributes. Some might deal with interpreting results, e.g. advisory-vote, others might deal with setting the approval required. Note "Advisory Vote Only" might be <PassageThreshold>

Without a link from a recall contest to the replacement contest, an app that interprets election results would need to parse the contest titles to try to reconstruct the missing information.

An app interpreting results also needs to know if a runoff will be held. The CDF doesn't allow that info to be provided. It's been a big problem with the election info site I work on in presenting election results. It's very hard to get the runoff status for an contest, and really needs to be in the contest definition.

[johnpwack]

Carl, if I understand this correctly, the sole change you are recommending is to add a recall enumeration value to the BallotMeasureType enumeration?

[carl3]

John, I think adding a <ReplacementContest> IDREF is the best solution, so a new field means new subtype (since ReplacementContest only applies to a recall). But if <ReplacementContest> is not added, then adding "recall" to the enumeration type is sufficient.

[jdmgoogle]

I would strongly lean towards the new enumeration type, since <ReplacementContest> can get infeasible quickly if jurisdictions start trying to represent the relationships of conflicting ballot measures using this method.

[johnpwack]

Added 'recall' to BallotMeasureType.