Make chamber passage attributes on bill responses better

[dwillis]

Right now, bill responses have four attributes related to a bill's passage:

house_passage_vote and senate_passage_vote, indicating the date the bill had a roll call vote on passage (if any). If a bill passes without a roll call vote - by unanimous consent, for example - this value is null.

house_passage and senate_passage, which essentially duplicates the other set (and were brought over from Sunlight's API).

One improvement would be to have the latter set of attributes reflect date of passage by any means, including voice vote and unanimous consent.

[dwillis]

Here's a proposal: change the house_passage and senate_passage attributes on bills to boolean values instead of dates (which are represented in house_passage_vote and senate_passage_vote. These booleans would reflect passage by any means - a roll call vote, unanimous consent or other means. Thoughts?

[phil-harmoniq]

Is this intended for a separate version of the API? I would have to vote no if it's a breaking change in the current API. I do however agree with the reasoning.

[ali-aka-ahmed]

That update would be great! Would love to get that update.

[dwillis]

@phil-harmoniq It would be a breaking change, but the same information currently is duplicated by the house_passage_vote and senate_passage_vote attributes. Does that make a difference?

[konklone]

The Sunlight API consistently broke each history event out into two fields - one indicating the result (and whether it happened), and one indicating a date that it happened (if it did):

https://sunlightlabs.github.io/congress/bills.html#history

For some events where a bill has a clean boolean state (e.g. whether it's law or not, or whether it's been vetoed or not) the first field is a boolean. For other events, such as a vote, where it can either pass, fail, or not happen, then the first field is a string that can be "pass", "fail" or be null/nonexistent to mean that it never happened. All 3 of those are useful semantic states.

For events with a clean boolean state, the date field indicates when the value changed. A null/nonexistent value means the event is in its default state (e.g. false for enacted) and so no event occurred. For events where it can pass, fail, or not happen, then the date indicates when the passage or failure occurred. A null/nonexistent value means that nothing happened, and that the first field is null/nonexistent as well.

I think those fields and values captures the range of possibilities, and lets clients make consistent meaningful decisions about any of the different states, while keeping expectations about field structure consistent for developers.