-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle VoteEvent
s that address the passage of _multiple_ Bill
s
#308
Comments
Almost all the votes in the Chicago City Council are like this. |
@fgregg, how do you currently model those? |
They get modeled as separate vote events. |
But ideally they would be a single |
Sorry, yes. I meant to be supportive of this modeling change by giving example of this pattern. I would definitely support a more accurate voteevent. |
This should probably be an OCDEP not a pupa issue as we'd have to make the
change there & in py-ocd
As for the issue at hand, it'd be a pretty big breaking change unless we
kept around VoteEvent.bill and had an optional VoteEvent.bills or similar.
I am conflicted on that one as it'd let us keep backwards-compatibility &
allow the 90% case to be optimized but would quite possibly get confusing.
…On Mon, Jan 29, 2018 at 12:43 PM, Forest Gregg ***@***.***> wrote:
Sorry, yes. I meant to be supportive of this modeling change by giving
example of this pattern.
I would definitely support a more accurate voteevent.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#308 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAAfYr9_Ir9BFdMVP5di7Ha_iraxOCLPks5tPgMogaJpZM4RxCx5>
.
|
There is a legislative procedure known as "consent agenda" or "consent calendar," that allows for quick passage of innocuous legislation. In this system, a single
VoteEvent
can be on the passage of multipleBill
s; a 1:M relationship that Pupa doesn't currently allow for.One solution would be to add
related_entities
to the modeling ofVoteEvent
s, analogous toBill.actions
objects'related_entities
. This feels slightly off, since a more native solution would perhaps allowVoteEvent.bill
to accept both a Pupa ID/pseudo-ID (ie, current behavior) or an array of these IDs; however, that may be too big of a modeling change for an edge case such as this.Real-world examples exist in SD and PA, at least: https://github.com/openstates/openstates/issues/2100
The text was updated successfully, but these errors were encountered: