"First elected" about webvoteview HOT 6 OPEN

Is this a page we want to have persons or 'members' (i.e. congress-icpsr
pairs)?

On Wed, Sep 14, 2016 at 10:24 PM, Aaron Rudkin [email protected]
wrote:

Currently, "first elected" shows when the person was first elected to
congress. Jeff expressed that for the congressional seniority sort, it
should instead use when the person was first elected to their current
chamber. This would probably require rejiggering either the old or new db
schemas.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#19, or mute the
thread
https://github.com/notifications/unsubscribe-auth/AS6QixJ9ZITA-QkXzFNSRXopmz554IDfks5qqNacgaJpZM4J9ght
.

from webvoteview.

This is not really a page at all. It's just a property of several pages (i.e. congress listings, party listings). Currently both pages use "distinct" sortings (persons) even on the old schema, so you don't get duplicates of the same person. The data that drives this is the congresses field on voteview_members in the old schema. Congresses is a list of lists, each list being a continuous run of congresses someone is in. The sort value is the begin period of the first set of congresses. We would need to convert these 2-tuples into 3-tuples to add a chamber, and then the sort code would check for that.

Sort either of these pages by seniority.
http://128.97.229.160/congress/senate
http://128.97.229.160/parties/555

Jeff noted that Chuck Schumer sorts incorrectly on seniority in this wiki article:
https://github.com/JeffreyBLewis/WebVoteView/wiki/Things-to-add-or-fix

from webvoteview.

It is possible to get duplicates, for instance Ben Campbell in S104, who changed party mid-congress. This may be the desired behavior, though, since he has two different ICPSRs and nominate scores during that congress.

In this particular case, he changed party in his first congress, so the duplicates are adjacent, being a freshman in both cases. However, in the general case, if a legislator changes party in a congress after their first, however, they'll appear twice and separately in the list. This could result in a user missing the member they're looking for, because they find the pre-change member when they meant the post-change person, or they might not realize there are two at all.

Should the unit of first-elected be the icpsr or the person? @JeffreyBLewis

from webvoteview.

Interesting. I would think first elected should refer to the DNA not the
party-DNA. On the other hand, maybe it should refer to the
person-chamber. That is, the question is when where you first elected the
office that you hold so that Chuck Schumer doesn't look like a long-time
Senator when he moves from the House.

Best,

Jeff

On Thu, Sep 15, 2016 at 10:27 AM, adamboche [email protected]
wrote:

It is possible to get duplicates, for instance Ben Campbell in S104, who
changed party mid-congress. This may be the desired behavior, though, since
he has two different ICPSRs and nominate scores during that congress.

In this particular case, he changed party in his first congress, so the
duplicates are adjacent, being a freshman in both cases. However, in the
general case, if a legislator changes party in a congress after their
first, however, they'll appear twice and separately in the list. This could
result in a user missing the member they're looking for, because they find
the pre-change member when they meant the post-change person, or they might
not realize there are two at all.

Should the unit of first-elected be the icpsr or the person?
@JeffreyBLewis https://github.com/JeffreyBLewis

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#19 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEinZVHH5jzys2N-kOY1qd_fxwiBqurJks5qqYALgaJpZM4J9ght
.

Jeffrey B. Lewis
Professor and Chair
Department of Political Science
University of California, Los Angeles
BOX 951472, 4289A Bunche Hall
Los Angeles, CA 90095-1472

President
The Society for Political Methodology

from webvoteview.

RE: "This could result in a user missing the member they're looking for, because they find the pre-change member when they meant the post-change person, or they might not realize there are two at all." we do have a safeguard against this--member pages will helpfully direct you to previous or subsequent incarnations of the same person. So they might miss on their first click, but we don't dead end them.

(Not that this distracts from the broader point about the feature!)

from webvoteview.

This ended up being a little easier than I thought. It's only in the old schema, but basically I gave each ICPSR a "electedSenate" or "electedHouse" field as appropriate, and the seniority ranking on the congress pages now sorts by chamber seniority.

Schumer now sorts in the late 90s rather than the early 80s.

Not done:

• Tracking seniority across party switching
• the "Elected" text under members still says their first date of election.
• Seniority for people who are elected, defeated/retire, and then are elected again still calculates to their earlier date--so if/when Russ Feingold is re-elected, he'll sort as 1993 rather than 2017.

I think longer term on the new schema the correct approach is to retain buckets of continuous service for both the combined chambers and the individual chambers; and then for the nth congress, look at the beginning of the relevant chamber bucket to get seniority.

from webvoteview.