How do the campaign finance `Committee` and core `Organization` models overlap?

[gordonje]

I'm working on filling out @aepton's implementation of the Campaign Finance enhancement proposal, and I've uncovered an issue @jamesturk might need to consider sooner rather than later.

In the campaign finance OCDEP, Committee is described as a "Subclass of Popolo Organization", and adds a couple of attributes not expected on the base class. The existing OCD Organization class is a non-abstract model, and my understanding is that, as a general rule, we don't want to subclass non-abstract models.

This is similar to the Event/Election situation we got into previously. The solution then was to partially copy the definition of the Event model and create a new Election model. We also copied the definitions of the EventIdentifier and EventSource models to make new ElectionIdentifier and ElectionSource models.

I'm following this same approach for Committee and it's related models, but a few things give me pause:

1. Whereas, Event was in the legislative module and was tailored to those use cases, Organization is in the core module and is defined rather generically.
2. Organization has a couple of other related model that Committee also needs:
   • OrganizationIdentifier for storing alternate ids for the campaign finance committee
   • OrganizationName for storing the committee's various different names
   • Membership and Post for storing relationships committees and their treasurers, officers, staff, etc.
   • Maybe also OrganizationSource and OrganizationContactDetails
3. In the campaign finance spec, each Transaction has a .sender and .recipient each of which will have either a .person or .organization attribute populated, depending on the entity type. Under the current pattern, I think we also need a .committee attribute, since these can also send and receive transactions.
4. While I don't foresee the need to represent an election as any other OCD data type, I can foresee needing to represent a single organization as a campaign finance committee as well as other types of organizations (e.g., political parties).

If 4 is a real need, then it feels like exactly what Django's multi-table inheritance was designed for. Even if it isn't, multi-table inheritance would also address the issues raised in 2 and 3.

[aepton]

1 (and also 2, I guess): So Organization is in the core module and defined generically, but it's non-abstract? I'm far out of my depth re: Popolo and OCD classifications, but those seem like reasons it'd be a fair candidate for subclassing.

3: Yes, for sure. Though, since it's not always clear from a disclosure whether a donor is a person, company or even committee, would it be better to have a generic donor entity with flags for person, committee or organization? Not sure how to distinguish between the latter two; companies are clearly organizations and not committees; on the other hand, the entity doing the donating on behalf of a company is often a committee set up by that company. Some disclosures in some jurisdictions, filed by some campaigns, make it (reasonably) clear which is which, but many do not.

4: Yeah, there can be fairly intricate relationships between different types of committees and organizations. In WA, the state D and R parties have specific committees who fundraise and make donations to candidates in each chamber of the legislature (Kennedy Fund, Truman Fund, etc). Those committees are essentially controlled by the state parties, but nominally different entities.