access-missouri / am-django-project Goto Github PK

Since the OCD models are not abstract, we have to address some of the issues we may run into by using this "just add water" approach vs. re-inventing the wheel on our own. I certainly see merits of both, and I think this is a discussion worth taking on.

Some We Should Assume When Making This Decision

I'm not saying they'll all be true, but if we assume these things, we'll make the most forward thinking decision we can.

• Access Missouri will eventually be entirely Django-powered, including the views, and a path to baking those views should be pretty straightforward.
• We will need admin interfaces for every model.
• Access Missouri may eventually integrate its own news blog - this means we need to be sure we have a way to mesh these models with posts, newsletters, et cetera.
• Access Missouri will probably include user-based dashboards at some point, so these models should be ready to integrate with models for those as well.
• Access Missouri must be maintainable in the long term, whether or not we're around.
• Everything feature accessible to an end user in Access Missouri, whether they're on the site or an API consumer, must be clearly documented.
• We need full Python 2 and 3 compatibility.

Some Immediate Pros to Using OpenCivicData

• Interoperability of our code with others' work - another state could immediately pick up some of our work and use it themselves.
• Interoperability with services we don't build - it would be very easy to connect to APIs or systems that happen to use OCD standards.
• We don't have to think about the finance and person models which quite frankly scare me.
• Other people have already worked on creating relational architecture that hopefully makes a lot of sense, so we don't have to think about some of these bare bones basics, meaning we can focus on functionality instead.
• Potentially time saving: We don't have to write our own models.

Some Immediate Cons to OpenCivicData

• The OpenCivicData models are made to fit almost any possible scenario, meaning there's a lot of potential cruft there.
• Terminology used in OpenCivicData does not necessarily align with terminology used in Missouri government, so if we used theirs, we would be spending time figuring out how to map things where they belonged. If we made our own, this wouldn't necessarily be a problem.
• No access to define class methods like __str__, __eq__, or get_absolute_url.
• No access to the Meta class, so things like class-defined ordering, labels/verbose names (which, as defined above, may vary from the OCD needs and will add complication to admin writing), indexes (again, a real time saver in admin and view building), latest_by/get_latest_by, and permissions (potentially useful for creating robust admin).
• Other people put together these models - we are subject to their whims.
• No centralized, authoritative package home that is up to date; right now we're pulling from CCDC.
• Potentially time wasting: We get to spend however long it takes deciphering documentation written in different stages of development and agreement about these standards, not to mention the code that others have written.

So yeah. Thoughts?

Will need to use BillVote for ordering - easy to do.

It should at least push a link to the pdf.

Bill status right now is done in Python with some pretty data-hungry logic. This means it's only useful on single bills, otherwise the time it takes outlasts the AWS Lambda TTL - also page load time would be ridiculous.

So this needs to get cached somehow. I don't want to think about this right this second, so I'll work around including bill status, but there are places it would be nice, and the ability to add a status slider to search would be neat.

Recent bills, financial contributions? Should be pretty easy.

I'm not sure what we agreed upon - @gordonje, do you happen to still have those notes or the changes you made?

Maybe create a name_index field on Person model so it can be searched universally with low overhead - convenient for PDF scraping as well.

• No search button?
• Gift from the year 2100
• Largest gifts in the last 60 days item on the front page? Limit the recents to 5 or 6, push down, bringing up biggest.
• Transaction pages
• See more buttons
• "Most recent data may not always be available"

I suspect somewhere there's an update_or_create command with a nonetype association or some such nonesense.