is elections' Party entity necessary?

[jamesturk]

in https://github.com/opencivicdata/docs.opencivicdata.org/blob/master/proposals/drafts/elections.rst

a new Party type is created that is effectively a subclass of Organization that adds:

• color
• is_write_in
• abbreviation

I'm not convinced on any of these fields being appropriate for inclusion and want to discuss their purpose & usage.

color
Parties (in the US at least) don't have official colors, red & blue have only been in use for the past. This seems like a property that should exist in applications using colors to represent parties, not in the core metadata.

Looking at Wikipedia, it does seem that some parties in other countries have official colors, but it is often more than one.

is_write_in
This doesn't feel like a permanent feature of a party either, as it would vary a lot election to election. Ballot access is a complicated thing, in general no party is guaranteed ballot access in a particular race, it usually depending on their showing in the last election. A good example here would be the US Green party which has ballot access currently in 19 states, but that changes year to year.

abbreviation
This could be a useful addition, but I also wonder if it is redundant w/ alternate names.

It might make more sense to have a recommendation that organizations have an alternate name added with a particular note set.

Open to being convinced on any of these, but wanted to start the discussion before we had an implementation.

[gordonje]

These properties were all ported over from the Voting Information Project's Party element.

To be honest, the one that matters the most for our use cases in abbreviation. I could live without the rest until the need for them among ocd_django users becomes more apparent.

Abbreviation feels especially useful for political parties because labels for candidates, election results, graphics, etc, often use an abbreviated form of the party name (e.g. "D", "R", "I"). Filtering the specific preferred abbreviation out of a list of multiple alternate names feels like a hassle to me, and I also think something like an abbreviation or short name field on Organization makes sense generally.

It's also true that some political parties could have more than one abbreviated or shorter name (e.g., "R" and "GOP" for "Republican"). I don't mind those as alternate names. If we think adding a note field helps distinguish among various names for an org, I say go for it.

[gordonje]

I'll also add that our implementation currently includes Party/Organization objects with names like:

• "No Party Preference" for candidates who declined to declare a party when declaring candidacy for office.
• "Non-partisan" for candidates in non-partisan office (where the don't declare a political party when declaring candidacy).
• "Unknown Party" for candidates who we know should have a party (or "no party preference") but we haven't extracted this from a our various data sources.

These feel like they run counter to the idea of a Party being and Organization, but these are lookup values we need to have available along with the other actual political parties.

[jamesturk]

I'd like to get @jpmckinney's take on the abbreviation attribute. I generally think there's good reason for the way we do it with using a list of other names vs. having a short_name, long_name, alternate_name, etc. field and that same logic would apply here.

If we do decide we want a special abbreviation field, I'd suggest we just add it to Organization and do away with Party

[jpmckinney]

Yes, I think we can use other_names for this and just have a standard note to flag the particular name as being the canonical abbreviation. I have a much earlier discussion considering when to subclass.

I was a little more expedient than usual in reviewing the elections spec as it had been sitting for a long time, and I figured we'd but up against these sorts of issues during implementation (also, the spec was just moving from PR to 'draft', so it's still open to major changes).

[jpmckinney]

@gordonje Re: 'unknown party', etc. I create, for example, an 'Independent' party in my OCD implementation, even though the model then implies that those people are all members of one party with the name 'Independent'. I discuss how to properly model unknown or empty values but those 'proper' solutions are often unnecessarily complex; it's generally easier to just special-case the values like 'Independent' in an application's logic.

[gordonje]

@jpmckinney thanks for the helpful explainer. I suppose our version of your "Independent" will be "No Party Preference".

Okay, so I'm going about removing the Party model from our implementation. As I do that, what's the preferred name for foreign key fields that reference a subset of another models objects?

I'm inclined to keep party as the field name, even if there isn't an actual Party model. I don't like field name organization because it loses too much meaning. Is party_organization striking the right balance? @jamesturk maybe you have stronger feelings on this.

[jpmckinney]

Could you remind me which models would have that party foreign key field name?

[gordonje]

Candidacy, CandidateContest and PartyContest.

[jpmckinney]

I figure the range of those properties will only ever be an organization that is a party, so party seems fine to me.