Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple links between Committee and Jurisdiction #96

Open
gordonje opened this issue Nov 3, 2017 · 2 comments
Open

Multiple links between Committee and Jurisdiction #96

gordonje opened this issue Nov 3, 2017 · 2 comments

Comments

@gordonje
Copy link
Contributor

gordonje commented Nov 3, 2017

I'm working on filling out @aepton's implementation of the Campaign Finance enhancement proposal, and I've got a few questions regarding the spec.

Currently, a Committee can be linked to a Jurisdiction in at least two ways:

  1. A Committee references a CommitteeType which references a Jurisdiction.
  2. By subclassing Organization, Committee also inherits an optional reference to a Jurisdiction.

Feels redundant. Looking back at our earlier convo, seems like Committee Type was defined as its own data type because we believe the available types and their regulatory meanings will vary across jurisdictions.

I don't doubt this, but I wonder how much bearing it should have on the specification. Why does it matter if "candidate" type committees in WA file at a different frequency, disclose different transactions or otherwise have different rules from "candidate" type filing committees in IL? What's wrong with allowing the filings, transactions, etc. associated with these committees to differ depending on the committee's jurisdiction, even while they're all grouped under the same label?

This of course wouldn't rule out jurisdiction-specific ETL code for integrating the committees and filings into the jurisdictionally agnostic models. I'm just saying the rules surrounding committee types might not need to be reflected in the schema.

For now, I've left the .jurisdiction field off of the Committee model. But my proposal would be:

  1. Not include a Committee Type as it's own data type and, instead, have an open text .type or .classification field on Committee
  2. Just use the .jurisdiction field Committee inherits from Organization.
@aepton
Copy link
Contributor

aepton commented Nov 4, 2017

I vote for 1 (which, on reflection, isn't mutually exclusive with 2, and perhaps that was your point all along). I think Committee Type is a genuine thing that ought to be represented by this spec, but I also don't want the perfect to be the enemy of the good - it's certainly not the most important thing for the spec to describe.

There are a variety of rules at different jurisdictional levels that apply to certain Committee types and not others, way beyond just filing frequency. Contribution limits is the big one that occurs to me offhand.

That said, it's hard to see what wouldn't be accomplished by just allowing a free-text field for type attached to a Committee and then using Committee.jurisdiction to disambiguate between, say, Ohio and Florida PACs or whatever. As long as one ETL system is running for a given jurisdiction, it's easy to enforce consistency, and there's no expectation of cross-jurisdictional consistency in the committee types since no such thing exists in the real world. (Well, ok, it kinda exists but technically doesn't).

@aepton
Copy link
Contributor

aepton commented Dec 16, 2017

Fixed in #104

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants