-
Notifications
You must be signed in to change notification settings - Fork 4
Technical Overview
- What charts / tables / pages do we wish to show on the front-end?
- What API endpoints do we want to expose to the front-end?
- What Django models do we want to expose?
- What data (columns) do we want to pull?
For the first version, high level aggregates of how much money is going into a particular ballot topic (candidate office or ballot measure). The aggregates are broken down into "interesting" categories. Some examples:
- Money inside the jurisdiction vs outside the jurisdiction.
- Contribution size (small donors vs large donors vs self-funding, etc.).
The visualizations in the mocks are fairly simple, mostly to contrast the different categorizations.
If you have opinions or ideas, join #dataviz.
For the first version, our API is targeting our UI, it's not meant to be a public API for developers. Here are the endpoints I've identified for now.
| Endpoint | Description |
|---|---|
| city/:city_id | returns the city object for the city, includes city name, high-level totals of money within the city's election. |
| city/:city_id/ballot | returns the ballot object for the city, includes the combined contests of all jurisdictions within the city, since we're not supporting individual jurisdictions yet. |
| referendum/:referendum_id | the referendum (aka proposition or ballot measure) object with high-level contribution information included. |
| committee/:committee_id | a campaign committee with high-level contribution information included. |
| committee/:committee_id/contributors | returns a list of unique contributors who have contributed to this campaign committee. Must support paging query parameters. |
Notes:
- City should probably be named locality or metro.
- Ballot models/API should be based on the voter information project ideally.
Frontend folks hang out in #frontend, and the API folks hang out in #disclosure.
Again, we're targeting the UI, so using models that help to get the data to the UI gets us moving forward. It's fine to have some intermediate models, too. Also, we're looking at how to maintain data integrity and transparency when cleaning the data, possibly amending it for de-duplication, etc. There are some github issues about citations, and these topics. We're not trying to tackle these for v1, but would be happy to have folks thinking about it.
Currently we have a ballot app in the django project, and then the campaign finance data is in netfile app and the calaccess app. At some point these need to be combined for the frontend. Unclear if they should be implemented as django models, but if it simplifies development, then let's go for it.
Django folks hang out in #disclosure.
See Campaign Finance for a high-level overview of what relevant data are reported when, and Campaign Data Formats for how that relates to public data feeds.
How to compute totals by category at the city level, contest level, and contributor level should be relatively straightforward, given the data descriptions above.
If you're interested in helping to solve this problem, join the #campaignfinance Slack channel.