After the election, reading was how I spent my free time in November and December of 2016. That, and talking to my brilliant partner about all I was learning about political machinery. As it happens, she is a professor who teaches social policy and takes her students on field trips to the state capital in Topeka. She suggested that if the state legislature was so important, I should learn how it actually works: find a bill and follow it through the legislative process.
So I went to the Kansas legislature website and tried to figure out how to follow a bill. I found I could search bill text and find bills if I knew their number, but I could not find a feature that would send me email whenever the status of the bill changed: when it was going to be discussed in committee, or voted on, etc. I knew from using the federal congress.gov site that it was possible to get alerts on federal legislation emailed to me if I created an account. The same kind of follow-the-bill alerts feature did not seem to exist for the Kansas legislature.
I figured that someone must have solved this problem already. The closest I found was openstates.org which did not have the alerts feature but did have an API that I could use. After touching base with the OpenStates developers to see if the alerts feature was planned (it was but without a timeline), I decided to see how quickly I could prototype the legislative alerts feature myself. A classic yak shaving exercise. I had three design goals:
- The minimally viable product should take no more than a single weekend;
- Send alert emails for a single bill or a saved search (like a Google alert);
- Store the minimum amount of user account information possible.
Since I had been doing a lot of Ruby on Rails development for my day job, I decided to use that tool to meet goal number one. Goal number three was made possible thanks to the wonders of OAuth: I could let users log in using an existing account (Google, Twitter, GitHub, but not Facebook since I did not (yet) have a Facebook account). Goal number two proved to be the trickiest but that was where all the fun was. I found an existing Ruby client for the OpenStates API and after some experimentation, hit on a data model that did most of what I wanted. The end result seemed good enough to me that I decided to go ahead and register a domain name and set up a GitHub organization and a Twitter account. I figured I would use it, at least, and since it could search all US states, maybe others would find it useful.
What I did not know yet was what bill I should follow. This is what yak shaving can lead to: lots of energy spent working on the thing you think you need in order to do the thing you want to do, and then sort of forgetting about the thing that got you shaving that yak to begin with. (I did eventually find a bill to follow: my own.)
Each year since then I have updated the site to reflect changes to the OpenStates API and to make small improvements. But basically the site is as it was three years ago. It does one thing and it tries to do it well. I’m told that the OpenStates.org site itself will soon offer the same kind of functionality. When it does I’ll be glad to shut down legalerts.us and treat it as a learning exercise that helped me experience how a bill becomes a law.