Instead of many-to-many relationship between Filings and Elections, maybe a many-to-one relationship between Transactions and Elections?

[gordonje]

In CA, I believe all transactions in a filing apply to the same election, but seems like this isn't the case in other jurisdictions. For example, in our earlier convo, @LindsayYoung raised the point that in the FEC schema one filing could apply to multiple elections, especially during primary season.

However, Lindsay also suggested that "election is generally more useful on the transaction level". If so, modeling that transaction-to-election relationship feels more straight-forward and precise.

Would it be an improvement, then, if we:

1. Remove the repeating .election field from Filing
2. Added a non-repeating .election field to Transaction (and maybe CommitteeAttributeUpdate too)?

[jsfenfen]

In a technical sense, I'm not sure 'election' is the right term here... at the federal level folks can raise money for conventions, inaugurations, building funds, etc... Is the point here to allow math on what allotment of money raised can be spent on primary / general / run-off / legal expenses / etc? What about paying off debt incurred in a prior cycle? I'm curious if an election tag is really needed, or if there's a more generic tag we should allow.

[gordonje]

@jsfenfen Yes, I believe the main reason to tie either filings or transactions to elections is to track those donation and expenditure limits.

Neither the OCD elections or campaign finance enhancement proposal define anything like an "election cycle", and I'm not eager to figure out how to make something like that work for multiple countries. As long as, somewhere on the form or line item, there's either an election date or type (e.g., general, primary, special), we should be able to map that to an OCD election.

Would it work if the Transaction.election field value were optional? We would still have the Transaction.date field be required, so at least we would always know when the donation, expenditure, etc. happened.

[jsfenfen]

@gordonje that works for me!

[aepton]

Yeah, I think it should be optional, and maybe it should even be a free-text field that allows for things like "Inauguration" or whatever? I don't know if it should still be called election then; maybe designation or something?

[gordonje]

I think the API needs to allow easy grouping and aggregating of all transactions related to a specific election, as well as all elections in the same year or period of time. At least in the implementation in Django, this probably means we need a field that contains only election ids, not other values.

I was just reading this FEC explainer on contribution types, and it seems to me the term "designation" is used for describing the relationship between a contribution and the election/candidate (or ballot measure, I suppose) for the purposes of "avoid(ing) the possible appearance of excessive contributions on reports."

The other things we've named here strike me as fitting into a field called "purpose". Is this a field we need to add, or could this maybe fit into the .note field already on Transaction?

[aepton]

So yes, we absolutely want to be able to get all transactions for a given election, but the existence/possibility of disclosing inauguration and convention donations, as well as debt retirement after an election, means I think we can't assume that every transaction is tied to an "election" instance. It seems like it'll be jurisdiction-dependent, so I'd like to punt this a bit to the implementer for that jurisdiction.

I'm also on board with adding this into the repeated notes field - I think we want to avoid overspecifying at this point in the spec.

[aepton]

Fixed in https://github.com/opencivicdata/docs.opencivicdata.org/pull/104