-
Notifications
You must be signed in to change notification settings - Fork 20
Roadmap
- An account/subscription management interface
- Searching and subscribing by location (point and radius)
- Closer API conformance with OpenStates * It shouldn't be field-for-field, but there are commonalities that can and should be identified
There are a few useful and ideally independent parts of this project that could and perhaps should be their own services. If they were, it would simplify the code base that is Councilmatic, and allow these services to be used by other projects.
- Subscriptions The subscription framework is its own Django app (its tests should be better insulated from the rest of Councilmatic) and could be its own project/service that Councilmatic consumes. There are a number of other cases where it would be useful as well. Making sure that the app can act as a stand-alone project may improve the architecture and API of the app as well.
- Geocoding of text blobs The address parser and geocoder is pretty simple right now (address regular expression), but could stand for some major improvements. It would be easier to get more eyes on it if it were a standalone service that other people could consume as well.
There is quite a bit of momentum around local legislative data lately. Many people are asking whether it would be possible to do something like the Sunlight Foundation's OpenStates initiative with cities and other local governments. One thing (not the only thing, by a long shot) that Sunlight has done really well is to make their pieces modular. One piece in particular -- the Billy scraping framework -- is relevant to Councilmatic. A Billy-like framework for local legislative data would be a wonderful addition to this world of tools. Councilmatic should work to be Billy-compatible to lead this development.