new maintainer?

[jamesturk]

After a lot of consideration, I think we're heading towards a fork of the project for Open States' purposes. I'm not sure who else is using this project besides the Datamade team at this point, so most likely I'd turn it over to y'all if that's acceptable to you. I feel like py-ocd/pupa took us pretty far, but it might be time to say goodbye.

To explain why, over the past ~6 months I've been keeping a list of things I'd like to do to our schema that I think would be too radical to do as releases of py-ocd. A sampling:

• I'd like to move towards a data model that simplifies some of the post-membership-org stuff. That's a big complaint of people working with our data, and I think it'd make more sense for US/state politics to abstract more of that away.
• I'm also looking to explore an approach that uses fewer tables, taking advantage of ArrayField & JSONField a bit more. Nobody is querying on Sources/ContactDetails/BillActions etc. and I think in-lining those might lead to some real performance fixes. While we could in theory push forward on this within the existing py-ocd, we'd need to fork to our own version at least temporarily to try them out.
• The event system in general I think could be rethought
• There's an open question here & in pupa as to how specific our clean up can be. While the dream was to have that all be hot-pluggable/configurable on a per-instance setting, we never quite got there, and as a result sort of settled for lowest-common-denominiator checks that we all agreed upon. I'd like to start tightening our data quality controls/etc. and a fork is the quickest (but certainly not the only) path.

I wanted to put this out there formally before a decision was 100% final- I'm glad to discuss here or elsewhere.

(As for logistics, we'd probably start with a fork of this repo and rename it something like python-openstates-datamodel. I'd plan to leave this repo 100% intact for anyone else to take on.)

[jamesturk]

we're now pretty deep into the migration away from this, updating title to reflect status

[fgregg]

Hi @jamesturk, just seeing this now.

In general, be free! If this is not serving your purposes, then let it go. We can take on maintaince for this and related repos.

To your particular concerns, I do think we see some of them differently.

• I think it is hard to understand the difference post/membership/organization. But, after working with it for a few years, I now think that the difficulty is reflecting a real complexity in the world, not an infelicitous implementation. Showing that certain posts are not occupied, for example, has been important in some of our work.
• Totally agree that sources and contact information could be profitably inlined. We do query bill actions quite a lot to understand the status of a bill. I'm a bit surprised that that's not a common case for y'all.

The other points I don't really have enough context to weigh in, but i'm sure the freedom of a fork will help you sort that out.

It may turn out that we want to rejoin your fork at some point. The only point that we might be a real blocker is how to model posts/memberships.

[fgregg]

One concern I do have.

What does this mean for the OCDEP process. I think that it's been very useful to gather the small group of folks who think a lot about how to model civic data.

In principal, there's no conflict with you forking this and keeping with the the OCDEP process, but Posts, for example, are part of the OCD standard?

[jamesturk]

Re: OCDEP stuff, I wouldn't object to chiming in if my opinion proves useful on a future proposal, but we aren't going to be using OCD terminology in the next iteration of the Open States API/etc. beyond (probably) keeping the identifiers as they are.

[fgregg]

okay, good luck. it's been fun! you should be able to pass control to [email protected] on pypi and I can take it from there.