I found that "require 'sunlight-congress'", which is mentioned in the readme, does not work, but "require 'sunlight/congress'" does work.

You have require 'sunlight-congress' in the Usage section. I understand that is for the gem install, and easy to mix up while you're explaining it all.

That didn't work for me, I had to require 'sunlight/congress' in my app.

Is this a typo?

...in the example HTML code.

As Joe and I were implementing the Vote functionality, we realized that in the API calls, queries can be chained. For example,

/hearings?query=environment&chamber=senate

Unfortunately, we only implemented each attribute of the vote object returned individually. It looks like the Bill class was implemented the same way. We weren't immediately sure of how to make the methods chainable, because we would have to build up the API call out of strings that the methods returned, etc...we just decided to punt on that for now. How were we thinking of doing that, or has anyone broached that topic?

Under "Cleanly Displaying Legislator"

"Congress" is spelled as "Congres" in the example code.

So, a lot of the basic stuff has been done but I feel like there isn't really a decided way that the public facing API should look for things like filtering, querying, pagination etc etc.

There have been a couple of attempts but I haven't seen anything agreed upon. Can we come up with an agreed approach to this so that we can move forward?

I'm keen to contribute some code here but am unsure as to the best way forward.

Thoughts?

Hi guys - I built Sunlight's Congress API, and stumbled upon your work here. I'm taken aback at the pace of development and the number of contributors - what got this started? In general, feel free to CC me on any ticket where I can be of help.

And of course, if there are any bugs or requests for the API itself, I use Github Issues to manage that as well.

Hey Guys.

Im going threw your tutorial - http://tutorials.jumpstartlab.com/projects/eventmanager.html - and am running into problems as this gem is failing, and throws an error for the app.

Any idea when we can expect a fix?

Hey guys, just wondering when the next Ruby Gems version is being released?

I'm doing this JumpStart Lab tutorial: http://tutorials.jumpstartlab.com/projects/eventmanager.html
It uses the Sunlight::Congress::Legislator.by_zipcode(arg) method and works fine.

For some reason, however, when I tried using the by_state method with the same syntax I got a NoMethodError "undefined method `by_state' for Sunlight::Congress::Legislator:Class". The same happened with the "by_bioguide_id" method, too.

So I noticed that a little bit of coverage for Bills has been merged in - I was working on something in parallel and wanted to see if the way I was approaching it was worth taking a look at. Since the results returned by Bill are rather lengthy and at times may vary, I thought it might be a good place to use a Hashie::Mash to wrap the results. What I've come up with so far looks like this: rjsamson@f407376 and can be used as follows:

# returns all bills matching 'health care' of bill_type 's'
bill = Sunlight::Congress::Bill.search("health care", :bill_type => 's')
bill.num_pages
#=> 50  # 50 pages of results
bill.count
#=> 991  # 991 results returned
bill.results[0].short_title
#=> "Health Care Bureaucrats Elimination Act"

That is just a few examples, but all results returned are available as methods under results.

Is there any interest in moving this direction?

Just a question about the general module structure and assumptions. My first inclination was to move all external require statements into the congress.rb file and to take out the Sunlight::Congress module declaration from the top of legislator.rb. The goal would be to avoid repeating it at the top of every file, but it would require people to load the full api instead of being able to use just Sunlight::Congress::Legislator for example. Do you have a preference for how the module is structured, and if so is it the example in Legislator?