Princeton Undergraduate Student Government

There hasn't been an update on this blog in a while, but that's because I've been hard at work on a not-so-secret weapon.  You see, I have to confess that I was slightly disingenuous in the last blog post.  I insincerely wrote:

"So we still can use WebSurvey to run the election in the fall... this seems to be an acceptable option, and frankly the best that we can do."

In fact, we can -- and most certainly will -- do better.  All along, I was never actually content with settling for WebSurvey again; you can't succeed by settling for second-best.  Unfortunately, at the time of that last meeting and the blog post, "first-best" wasn't a viable option... yet.  But a few weeks, and a few hundred emails later, I present to you Princeton's very own functional instance of the Helios Voting Booth.

The Bait and Switch

Even though Helios was a mature system, ready to be used, it was not certain how Helios would interact with the University's authentication infrastructure. This additional connection that needed to happen was what stood in my way of convincingly proposing that we use Helios for the fall election.  Without solid evidence that Helios works for us, I would be standing on an unreliable footing -- pitching vaporware.  At the time, the best choice we could make was to fall back on WebSurvey, our old system.  I was okay with this decision since I knew that I'd be able to prove Helios in time for the fall election and that we wouldn't actually have to use WebSurvey.  Making this "decision" would then buy us time to do exactly that -- prove Helios.

The Missing Links

Every student has a personal netID that is the student's gateway to online services, from the Office of the Registrar's SCORE to University Webmail.  For elections, students log in to cast their votes using their netIDs.  Therefore, for us to use Helios, we had to configure Helios to play nicely with this infrastructure so that students could just log in with their netIDs to cast their ballots, and to ensure that voters cast only one ballot. (Actually, with Helios, voters can cast as many ballots as they like, but only the last one they submit counts.  But more on that later....)

We also needed to make sure that only eligible voters cast ballots.  In the upcoming fall election, only members of the class of 2013 are eligible to vote, so we have to make sure that only members of the class of 2013 can actually cast a ballot.  Lacking magical powers to deter ineligible voters (don't let Whitman College fool you into thinking this is Hogwarts), we had to somehow determine the class year of a voter.  The way we accomplish this is by using voters' netIDs to determine who they are via the university directory, the LDAP.  Give the LDAP a netID to look up, and the LDAP returns the class year of the student associated with that netID.  By simply checking whether that class year is eligible for the given election, we have successfully verified voter eligibility.

Although the LDAP is accurate 99% of the time, it is not a perfect database.  The information in the LDAP may be outdated because of extenuating circumstances, or a student may have requested that her information not appear in the public LDAP directory.  In these cases, the LDAP may erroneously indicate that an eligible voter is actually inelligible.  A better system would interact with the Registrar's database, which is more reliable.  However, such an interface would take too much time to implement right now, so we will tackle that hurdle later and instead handle LDAP issues on a case-by-case basis as they arise.

I will admit that this is settling for second-best, but I will also defend this choice with the following:

The old election system used this exact same method to determine eligibility, and suffered from the same problems, so there is a zero net gain/loss, and This is a complication I identified early in the election redesign process, before Helios was even part of our vocabulary, and one I am committed to overcoming when time permits, and We simply don't have enough time between now and the fall elections to make it happen. In conclusion, Helios with the LDAP limitation is still better than WebSurvey with the LDAP limitation, and we'll  resolve the issue as soon as we can.

The Goods

So after all of our work, we now have an implementation of Helios that successfully authenticates voters using CAS, the netID interface, and successfully verifies voter eligibility using the LDAP public directory.  At this point, Helios does everything to authenticate voters and check their eligibility that WebSurvey does.  But Helios is also... Helios.  And what exactly is Helios, you may wonder?  And why should you care that we're using Helios rather than WebSurvey?  Stay tuned for a future blog post where I'll actually outline all of the benefits of using Helios.  But for now, here is a video demonstration of Helios as it is right now.  I'd go into more detail, but I've got to get back to work on our remaining tweaks to Helios and then get the final approval to use Helios for the upcoming election.  Wish us luck!

Oh, and by the way.  Remember the $7,500 to $15,000 budget of last spring?  Well, Helios is free.  Now doesn't that just put a cherry on top?

 

Today we had our most productive meeting so far.  We now have a fairly concrete plan to succeed.  We reviewed our single proposal, reviewed the other options I proposed, and settled on a compromise solution.  But first, the background:

Introducing Dr. Ben Adida

I have introduced Dr. Kernighan and Dr. Felten before in this blog, but Dr. Adida is a new and most welcome addition to the team of experts I've been in touch with about the project.  I requested an email be sent to all Princeton Computer Science undergrads and grads, and one of the handful of responses I received was a suggestion to look into the Helios Voting System developed by Dr. Ben Adida.  Although I had come across a slew of run-of-the-mill online voting systems in our previous research, as I explored Helios, I recognized that this voting system was different from the rest.  It's the difference between an abacus and a TI-89; other voting sites count things, but Helios brings some sophisticated computing power.

Dr. Adida (who asks to be just called Ben) is a graduate of MIT who is a postdoctoral fellow at Harvard's Center for Research on Computation and Society.  He researches security and privacy in voting, health records, and web applications.  He is a member of the program committee for the Workshop On Trustworthy Elections (WOTE) and the USENIX/ACCURATE Electronic Voting Technology Workshop (EVT).  In fact, he and Dr. Felten will be brushing shoulders on August 10th at the EVT/WOTE 2009 in Montreal.  Could you imagine a better team of experts to advise our project?

Dr. Adida was kind enough to offer to speak with me by telephone last night.  I had only begun emailing him the day before.  We discussed his Helios system, Princeton's predicament, and the MedForward proposal.  Below are a few highlights from the conversation:

All elections have hiccups.  What differentiates successful elections from failures is how these hiccups are handled. Our best bet with our elections project is to be "iterative and conservative."  Rather than completing the system in one shot, it is in our best interest to make realistic goals and continuously develop the system for some time until it is ready. Although Princeton currently uses Single Transferrable Vote for certain election needs, Range Voting could be a more straightforward alternative. With the Helios Voting System, voters get the freedom to observe the election and make sure everything is okay.

The Helios Voting System

So I've mentioned the Helios Voting System, but not yet what it is.  So what is it?  In short, it is a cutting edge online election system that puts the power to audit the election in the hands of the voters and observers.  Helios allows voters to make sure their vote counted, to modify their vote before the close of the election, and to audit the entire election once the scores are tallied.  It leverages advanced cryptography to ensure vote security and voter anonymity, while simultaneously improving overall election transparency.

Learn about cryptography and voting in a Google TechTalk video presentation given by Dr. Adida.

This all sounds great, but does it actually work?  To my delight, Helios actually works very well.  In fact, the Université catholique de Louvain (UCL) used Helios to conduct an election for their university president, and it was no small deal. Below is an excerpt from their site (warning: it is a Google automatic translation cleaned up for enhanced English readability by me)

It is apparent that, with our 24,000 voters, electronic voting is the best solution, and that this system must be reliable and ensure the highest degree of security and confidentiality. Fortunately, the election commission has the help of Professor Jean-Jacques Quisquater, an expert in cryptography.  After studying a variety of voting systems with his team, he suggested Helios, a system designed by a Harvard professor (Ben Adidas).Three reasons motivated this choice, says Professor Olivier Pereira. First, voters have a high level of control at each stage, and we can verify that everything is operating correctly, and thanks to the internet, a voter can verify that her vote has been recorded. This system produces the weighted count of the ballots submitted by voters, nobody (nor even a computer) can ever determine who voted for whom.  Finally, the system makes it virtually impossible to vote incorrectly: first, the voter is prompted to confirm his vote, and then he has the opportunity to vote again if he thinks he is having a problem or made a mistake (that is one of the great peculiarities of the system). Helios has, of course, been adapted to the needs of the UCL. This has been the work for several months of Olivier Pereira and Olivier de Marneffe  in collaboration with Ben Adidas and the General Information System (ISMS) [presumably the equivalent of Princeton's OIT]. Among the challenges, they had to ensure "the soundness of the system given the large amount of data to be processed and the risk of attacks." That is why he suggested service providers, namely Amazon and Google: Amazon hosts the interface designed by UCL, and Google will store the data. "The best way to ensure the availability of the voting system for the duration of the election was to have extremely powerful servers  arranged across the world.  That is what we use Google and Amazon," explain two members of the technical team.

Source: UCL Website via Google Translation

During the first round of voting, one of the candidates missed the majority by just 2 weighted votes (faculty votes counted more than student votes in this election).  An independent company also audited the election, and certified that Helios had correctly tallied the votes.  A second election was held, and that candidate finally achieved the majority he needed.  In a paper detailing the outcome of the election, Dr. Adida and his colleagues at UCL write:

The deployment of an open-audit voting systems brings a number of small changes in the voting process, which inevitably makes voters suspicious. Numerous presentations were given and discussions fostered make voters more familiar and comfortable with the system. The features that were the topic of significant questions and debates were: (i) the possibility to revote, (ii) the identification of the voter at the time of ballot submission (instead of before the ballot creation), and (iii) the point of the bulletin board audit day (which delayed the announcement of the election results). From anecdotal evidence and the small number of complaints, it appears eventual acceptance of the system was quite high.

What Can Be Done with Helios?Helios will soon be released as an open source project written in Django, a rapid web development framework based on Python (An older version of Helios is open source too, and is available here).  The Django connection is particularly exciting, given the number of students at Princeton who have worked with Django and know how to use it.  In fact, the group of students that came together under the assumption that they would be building a voting system from scratch had planned to use Django anyway.  So this means that rather than starting from scratch, this group could simply extend the work of Dr. Adida, and modify Helios to meet our own specific needs.  All of the hard work of ensuring the system tallies votes correctly has been done!  All that remains to be added is the administrative and registration component, where candidates and referendum advocates can sign on and register for the election, and where the elections managers can manage these positions.  Amazing, right?

The MedForward ProposalWhen we sat down for today's meeting, we began by reviewing our one and only response to our RFP.  I highlighted some of the benefits and drawbacks of this proposal:

 

Positive Negative On TimeMedForward promises to deliver the system on time. Lack of Elections ExpertiseMedForward specializes in building websites for medical professionals, not building secure election systems. Meets Most RequestsThey have committed to satisfying most of our requests for the implementation. Use of ASP.NET and Windows Server 2003The platform has a steep learning curve if students ever need to modify it, and it will be difficult to obtain affordable server space running Windows Server 2003 and to keep running this older technology for up to 10 years. Potential for Future SupportMedForward will likely be able to support the system after it is built, through the lifetime of the system. MedForward Retains Intellectual PropertyAfter Princeton pays to have the system built, MedForward will retain ownership of the code and related intellectual property. On BudgetThe proposed price is within our original expectation of $7,500 to $15,000. Potential to Become ExpensiveThe price does not include the Single Transferrable Vote system, which will cost $2,000 more to develop, and combined with the additional costs of support and maintaining the required server, the lifetime costs could approach $20,000.

After weighing these positives and negatives, we decided against choosing the MedForward proposal.  Chief among our concerns was how developing voting systems is not something MedForward has done before.  After consulting with Dr. Kernighan and Dr. Adida, both expressed concerns about the complications inherent in developing online voting systems, and were unsure how well MedForward, or anyone, could implement the system we designed with just over one month to do so.  Dr. Adida recalls one voting system he built taking two years to complete.  And Dr. Kernighan wrote to me via email, "MedForward is presumably a fine company, but they claim no experience with voting systems, which have different constraints than most commercial systems.  For instance, voting systems have to authenticate the user, permit him or her to vote only once, and make it impossible to determine how the user voted." It's far more important to me that we come upon an airtight system that will last for up to 10 years, rather than settle quickly and potentially regret making a hasty decision.  So although I was extremely pleased to receive the proposal by MedForward, and we appreciate their offer to help us, in the end we felt that it was too risky to select them.  This decision was unanimous among the committee members in attendance.UPDATE 9/29/09: At the request of MedForward, I have redacted the price of the project in their proposal.

Download the MedForward Proposal

What Now?

Considering that we decided to decline the proposal from MedForward, we now found ourselves without a developer, and no guarantee of a new system by September.  This looks bad, huh?  Actually, I think we're in even better shape than we would have been if we had begun developing the system with a professional developer.  Let me explain.

After speaking with Dr. Adida, I know that our September deadline to develop a complex voting system may have been too optimistic.  I was cautiously optimistic last May, but it looks like my cautious choice of words, "it would be 'ideal' to have the new system in place for the Class of 2013 elections next fall," was duly necessary.  This isn't as much an "I told you so" as it is a recognition that this project was more complicated than we had hoped.  So even though we won't have a new system in use by September, we have accumulated crucial insights from the panel of experts and have discovered Helios.  In the end, the result will be better than if we made hasty decisions in order to have the system ready by September.

One Suggestion

I suggested to the group that we may be able to use a minimally adapted version of Helios in order to run the class of 2013 elections this fall so that we can at the very least have something new and reliable in use to tally the votes.  Helios doesn't currently support Single Transferrable Vote, but the upcoming election doesn't require that.  In fact, Helios can do everything WebSurvey (our previous election system) does for the fall election, plus Helios offers the advanced security and transparency features. All that would have to be changed would be to allow Helios to use our CAS netID authentication system, and to communicate with the Registrar's database in order to verify the class year of the voter.

So, considering that I hope to use Helios as the backbone of our new system we will develop, I suggested we begin using Helios for the fall election instead of WebSurvey.  This would be an ideal election to begin using Helios: it is the smallest and simplest of all of the elections.  However, the committee was uncomfortable using Helios right now.  Instead, they suggested that we continue using WebSurvey, so this was the option we are compelled to take.

More WebSurvey?

You may be saying to yourself, "More WebSurvey?  That's the system we had so much trouble with in the first place!  How can you claim that we've made any progress if we're still using WebSurvey?"  That's a good question, and the answer requires understanding exactly why we've had trouble with WebSurvey to realize that WebSurvey didn't cause the problems we've had, it only contributed.  As Daisy says in The Great Gatsby, "it takes two bad drivers to cause an accident" (not a direct quote).  So who was the other "bad driver?"  Sub-par elections administration.

Pointing fingers is a poor way to make progress, but we need to point the finger so we know where to make improvements.  So I'll review some of the reasons why previous elections have been problematic:

Winter 2008

Problem 1: Admin Access

In the news

"USG Elections Process Under Question" - November 19, 2008 (DP) "Voting delays explained at USG meeting" - December 8, 2008 (DP) "Weinberg '11 wins; USG nixes revote" - December 10, 2008 (DP) "An election to Remember" - December 12, 2008 (DP)

What happened?

Because of unusual circumstances in which the USG President openly supported a candidate and spread misinformation about another candidate's endorsement, the senate was tasked with deciding whether to conduct a revote after the original vote had already taken place.  There was suspicion that the USG President based his sway on whether to conduct a revote on knowledge of the turnout of the first vote that he wrongfully obtained via logging into the voting system to obtain the results.

What can be done to prevent it?

It was suspected that the USG President accessed the election results by logging in with the USG@ shared netID, which, in addition to the USGVote@ netID, had access to the voting system and the results.  Immediately following this allegation, changes were made to block the usg@ netID from gaining access to the system.  Therefore, this type of problem has been addressed.  However, the USGVote netID could also potentially be shared, which would grant access to anyone with the password.  Instead of using these shared netIDs to grant access, I suggest using personal netIDs, which are less likely to be shared and provide additional security.

Problem 2: Incorrect Vote Count Published

In the news

"Elections Audit Uncovers Erroneous Results" - May 22, 2009 (internal) "USG elections audit uncovers error; Class of 2012 Senate seat vacated" - May 24, 2009 (DP)

What happened?

The source of the problem was a quotation mark in one of the candidate's names.  This quotation mark caused the system to ignore votes for two candidates.  Every time a vote was disregarded, an error message was printed to the log where the vote counts are displayed.  There were 392 of these error messages.  There were other, negligible error messages, for when someone chose the same candidate twice for a senate seat.  The elections manager and the Registrar did not notice the unusual error messages, nor notice that the sum of all votes counted was remarkably less than would be expected.  The result based on the erroneous vote counts was published, but vote counts were not.

What can be done to prevent this?

First, the elections manager can more carefully inspected the system output to check all error messages and ensure that they don't affect the outcome of the election.  Next, the elections manager can compare the total number of votes cast with a calculated expected voter turnout, where this expected value is based on previous elections.  Then, the Registrar can double check the elections manager's checking.  And finally, the vote counts can be published, so that the public can also double check that votes were reported for every candidate, and that the vote numbers generally seemed to follow public preferences.

Spring 2009

Problem 1: Election start delay and erased votes

What happened?

Students began voting before the USG president had announced that voting had begun, and the ballot they were voting on was premature.  The USG president announced the actual start of voting when the ballot was ready, and all votes cast before then were not counted.

What can be done to prevent this?

Voting should not begin until the USG president's official announcement when it has been confirmed that the ballot is ready.

Problem 2: Incorrect scoring on Referendum I

In the news

"Correction to Referendum 1" - May 9, 2009 (internal) "Corrected referendum results show greater discontent" - May 15, 2009 (DP)

What happened?

There was a mismatch with how the elections manager created the XML file that creates the election, and how the election system tallied the results.  As a result, some responses were inverted.

What can be done to prevent this?

The XML file that creates the election (for WebSurvey only) can be verified before it is used.  And for a future system, there would be no need to manually map the database values with the choices -- it should be completely automatic so as to avoid any possibility of confusing them.

Notice a Trend?

Given these examples of problems that happened, the trend you may notice is that there were no problems that couldn't have been avoided were there some more comprehensive election oversight by humans.  Without a doubt, the technical system seeded some of the problems, but none of the final problems that occurred weren't preventable.  A better election protocol, including more time built in to allow for careful verification of all parts of the election, could compensate for these issues.

So what this means is perhaps the best change we can make is not to the technology but to ourselves.  The "ideal" voting system I designed, and we will still design, will help alleviate some of the issues that would require human oversight.  But that only makes it easier.  As Dr. Adida commented, all elections have problems.  The difference between a successful election and a failed election is how the administrators handle them.

Advice from the Expert: Dr. Ed Felten

As I mentioned in a previous post, Dr. Felten has become a part of our team of expert consultants.  When I mentioned the class of 2012 senator debacle, Dr. Felten offered:

Having read about the past botched election, my first thought was that the error would have been evident if the system reported results more fully and to a broader audience.    Just seeing no votes for certain candidates would have been a strong clue that something is wrong -- and the fact that the number of votes reported was many fewer than the number of voters would have been another giant red flag.

Therefore, I think it's in the best interest of everyone for the USG to commit to reporting all vote counts to the public.  This means every election, every position, and every candidate.  But Dr. Felten also agrees that the technology needs to change, too.

The people who saw the debugging output could have caught the error, in principle, but putting the blame on them seems too easy, and in my view that would miss some serious problems in the technology and -- at least as important -- in the human processes used in the election. The problem would have been detected if

(a) the system had shown voters the choices tabulated for them, at the time they voted, or

(b) vote totals for each candidate had been reported to the public or even to the candidates, or

(c) the error messages had been intelligible (it was a big problem that the real error messages looked very similar to messages that would normally occur), or

(d) the system had displayed a count of the number of errors of various types, in easy-to-read format, or

(e) the error messages had occurred somewhere other than a giant file of random-looking debugging output, or

(f) the system had been programmed to raise a red flag when the number of votes recorded was far less than the number of voters, or ....

Safeguards against error are the most important part of an election system.   Often the best safeguards are not technological at all, or involve only easy technical changes such as providing clear error reporting and building simple consistency checks into the system.

If you're wondering what the election output looks like, download the election output from the original class of 2012, December '08 election below.  This is an excerpt from the entire output, which includes the rest of the positions and referenda.  The header was added by my text-editing program when I made the PDF file, but the actual text as shown is unedited.  This is what the elections manager reads in order to determine the winner, and this is the text the Registrar reads to certify the election.  A little confusing, right?  No wonder there have been so many problems!

Download the original election output from the class of 2012, December 2008 ballot

 

Making WebSurvey Work for the Fall

So we still can use WebSurvey to run the election in the fall, as long as we implement a new, more thorough election protocol in order to prevent and mitigate any hiccups that can (and likely will) occur.  Given this additional time, we can then develop the system to make the technology work more effectively, too.  Although I would have liked to have had something more tangible to show for our work by September, this seems to be an acceptable option, and frankly the best that we can do.

What's Next?

Although we won't be using Helios for the fall election, and we won't have a new system developed by then, we will be simultaneously developing our own system that works with Helios and continuing to accept proposals from commercial developers.

By November 1, we will stop taking proposals and then compare the proposals we receive from commercial developers with the system developed by Princeton students that interacts with Helios.  We may then choose the system developed by the students, or we may select a commercial developer to execute the system.

What's the Timeline?

Starting immediately, the IT Committee and the Election System Developers will begin developing an administrative component that will interact with Helios (I'll continue describing this below).  By the first USG senate meeting, I will have a proposed protocol for the election.  Immediately after this protocol is adopted, we will begin planning for the election, which will include a meeting with the OIT technician responsible for WebSurvey, the elections managers, certain USG representatives, and the Registrar.  The election will take place in the beginning of October, using WebSurvey.  Then, in late October, using whatever parts of the Helios-USG collaborative project that is ready, we will conduct a pilot election -- perhaps a non-binding survey, a Mr./Mrs. Princeton contest, or just a mock election.  Based on that election, we will have gained valuable insight to how we can modify the system to be even more airtight.  Then, by November 1 (or around then), we will stop taking proposals and convene to review these proposals.  Then, we will compare the Helios-USG system with the top proposals (assuming there are any), and choose the best system.  If we decide to choose a commercial developer, then we will begin developing with them.  If we choose to use the Helios-USG system, then we will continue modifying that to be ready for the winter elections.  And then we will continue tweaking the system between elections until it is officially completed.

What will the new system look like?

If you haven't already visited www.HeliosVoting.org, check it out now!  In fact, create your own sample election, and vote in it.  You'll have to login with some Google ID, like a GMail account, since the system runs on Google's servers.

Helios already conducts the actual voting part very well, but it lacks the candidate/advocate self-registration aspect we would like to include.  The thought I have is that the student developers will create a standalone system (I'm informally calling this part "Luna."  And yes, I know Luna is Roman, not Greek like Helios, but I think "Luna" is more mainstream than "Selene," the Greek counterpart.) that allows candidates/advocates to register for the election and the elections manager to manage these candidates.  Then, once all candidates have registered and are verified, the elections manager essentially "flips a switch" that sends all of the information over to Helios for Helios to then create the ballots and prepare for voting.  This will create a special barrier between the two systems that will keep Helios as protected as possible.

However, before we actually decide what we are going to do, I have to arrange a phone call with Dr. Adida so we can carefully plan this.

As the wise Kel Mitchell once said, and the ever-sagacious Coolio sang, "Ah, here it goes!"

There have been a few important developments recently.

1) A bid comes in

Our first bid has come in on the elections project.  I will refrain from discussing the individual bids until all of the bids we could potentially receive have been submitted so as not to give other bidders any information they shouldn't have right now.  But I'll definitely post more about all of the bids once we've stopped taking them in.

2) Dr. Felten offers his support

Dr. Felten responded to my initial email, offering to provide whatever level of support his schedule permits.  I am excited to have Dr. Felten's expert advice contributing to our project

3) Message sent to COS grads and undergrads

A message was recently sent to all COS grads and undergrads requesting all those interested in either coding or advising to contact me by Thursday.  I hope to get some positive responses.

After waiting for two weeks to receive bids on our RFP, I just received bad news that we received zero bids.  Zip.  Nada.  This puts us in a very bad position.

We've just spent about 2 months trying to find someone to develop the site, and after two months, we've come up with nothing more than a further-refined plan of what the system should do and how it should function, but still nobody to do it.  September 15, my unofficial deadline, is now two weeks closer and we haven't progressed much since July 9.

So where do we go from here?  First I'll take an inventory of what we do have:

What we have:

A very detailed specification of what the system should function like A panel of supportive administrators including Ms. Griffin (Registrar) and Dean Dunne The support of OIT A newly-expanded team of talented IT Committee members A mandate to get this system completed by the class of 2013 elections this fall

What we need:

Someone (or some people) who will develop the system

Given this, I'm considering what alternatives we have now.  We've been pursuing the comercial developer route, which has taken two months and yielded nothing.  I think the best alternative now would be to stop and look around.  Princeton is full of highly-talented coders who can develop this system without a sweat.  Is there a way to utilize this abundant resource?

We had already considered having students build the system, but we had decided against it when the Registrar expressed concerns about certifying results produced by a student-coded system.  Understandably, the Registrar has a reputation to protect, and it could be risky to put that reputation on the line with a system built by students.

So how can we overcome this problem?  My suggestion is that we have students develop it, but under the careful guidance of a committee of experts.  This is Princeton, and we are fortunate to have one of the nation's strongest computer science departments.  In fact, our very own Dr. Ed Felten and Dr. Andrew Appel gained national recognition by uncovering vulnerabilities in the Sequoia Advantage electronic voting machines used by the State of New Jersey.  Given all of this talent, one would think that Princeton could figure out how to run a reliable student government election...

My suggestion is that we form (very quickly!) a panel of these experts.  I have already been in contact with Dr. Brian Kernighan, a computer scientist whose reputation precedes him and the professor of COS 333, the class where students build web applications as their capstone project.  Dr. Kernighan expressed interest in the project, and recommended me to reach out to Dr. Felten and Dr. Appel.

 

 

 

At today’s meeting, the USG Elections Advisory Committee convened to hear a report given by Matt Immordino.  Matt started by noting that after his research since the last meeting, he concluded that there does not currently exist a solution that could be purchased that would adequately match our requirements.  Therefore, in order to meet our requirements, we are likely going to need to develop a custom system.Next, Matt gave an overview of what other members of the Ivy Plus college administrators’ forum reported.  At MIT, for example, they still use paper ballots.  At Stanford the elections are done via an electronic system not much unlike the one we currently have, a system where the candidate’s statement and photograph do not appear on the ballot.  These were the only two responses received from Ivy Plus.Then, I added some information that I learned by speaking with a friend of mine on the Ivy Council from Yale, Rustin Fakheri.  Rustin explained that Yale uses a system that is remarkably close to what we would like to have.  Yale’s election system resides on their YaleStation website, a system much like our own Point – a student-built, student-serving portal for campus events, news, and communications.  Like Princeton Point, YaleStation, and the integrated Yale voting system, was designed by a student on the Yale College Council (abbreviated YCC, analogous to our USG).  When the student originally designed the system, he did not charge for his work.  However, he later created a web application programming company, and he now charges for maintaining the system.Given this development, I was able to once again advocate having a student or former student (collectively, from now on, just “student”) develop the system.   It appeared last time that this option was impracticable based on concerns by other members of the committee, but now Yale sets a powerful precedent.   If Yale had a student develop their voting system, and they have been using it reliably for the past few years already, that speaks volumes about the ability of a student to develop a system of this caliber and for this purpose.I am convinced based on the quality of work I have seen from students (Point, Room Draw Guide, Student Course Guide, the forthcoming Princeton Textbook Exchange) that a student can certainly develop web systems as good or even better than the professionals.  Although professionals may have more experience, students are more in-tune with the usability features that our generation has come to expect – simplicity and fluidity.  Also, whereas professionals will be charging fair rates for their work, as they rightfully should, a student will gladly work for less.  And quite frankly, a Princeton student may even be more meticulous and deliver a higher-quality solution than a professional because A) Princeton students are usually perfectionists and B) a student would have a personal vested interest in developing the system to improve Princeton and build his reputation to generate future business opportunities.Of course, this isn’t to say that I wouldn’t support working with a professional development company.  There are numerous advantages to that route, too, from the developer’s insight that comes with doing this for a living, to the accountability of a company to stand behind its product.  However, in order to compete with a student developer for this project, a professional developer has to be able to match or exceed a student’s affordability, flexibility, and use of cutting-edge interfaces and designs.After everyone had adequately discussed the options we now had before us, we decided to go about selecting a developer via a competitive bidding process using a Request For Proposal (RFP, also Request For Quotation, RFQ).   The process involves us developing the RFP document that outlines requirements for the project.  Then, within a certain bidding period, developers may respond to the RFP, indicating the cost at which they will develop the system and which of the requirements they will be able to meet.This RFP process will allow developers to respond to a uniform request, which means we can then evaluate them all fairly.  In addition, the process allows all types of developers to respond: students, freelancers, professionals.Unfortunately, this will now add about 1 month of processing and delay, since after we publish the RFP we have to wait at least 2 weeks for responses.  Then, once again, we’ll have to convene to review the bidders and select one.  Finally, after we have chosen the developer, we can begin developing the system, which may ironically be simpler than choosing how to develop the system.The current timeline for this is to have an RFP ready for review on Wednesday, July 1, to be published the next day.  Then, we will give bidders approximately two weeks to respond.  Once the open application process closes, we will individually review the applicants and the convene the committee to choose one.  The tentative date for this meeting is Tuesday, July 21.Although I’m disappointed that we are getting bogged down by the process, I am exceedingly glad that we have the support of so many extraordinary members who are all so dedicated to the process.  The September 15th unofficial deadline is approaching quickly, but I am still hopeful that we will have at the very least a new voting system with some of the bells and whistles ready.  Luckily, the October election is the 2013 class government election which is our smallest election.  Then, we can continue adding to the system between then and the next election, the Winter 2009 USG election in which positions such as USG President, Vice President, and all of the senatorial seats are up for reelection.  My fingers are crossed for a smooth election year, even with the new system making its debut.

Because of an increasing demand for IT-related services within the USG, the IT Committee has been restructured and new opportunities have been created.  There are five positions currently available to be filled:

IT Committee - Chair, Michael Yaroshefsky Product Support Chair, Solomon Abiola Vice Chair, Daniel Dix Product Specialist, Vacant Support Manager, Vacant Web Application Development  Chair, Hao Lian Vice Chair, Vacant Chief Developer, Vacant Chief Designer, Vacant

The online application and additional information about each position is available here.

Applications are due on July 17th at 11:59 pm.

At today's meeting, members from the Princeton Survey Research Center joined us, further expanding what I will now call the USG Elections Advisory Council.  This interoffice council that will continue to meet through the summer now consists of the following members:

Organization Representatives Undergraduate Student Government Michael Yaroshefsky, IT Chair Office of the Dean of Undergraduate Students Thomas Dunne, Associate Dean Office of the Registrar Polly Griffen, Registrar Amy Hughes Laurie Smethurst Anahit Mailyan OIT Departmental Application Services (DAS) David Herrington, Director James Chu OIT Technology Consulting Services Salvador Rosario, Manager Matthew Immordino Princeton Survey Research Center Edward Freeland, Associate Director Naila Rahman

 

Since the previous meeting, Matt Immordino and I met to determine which features the ideal elections system would include.  For the meeting, I created the following three documents:

Elections Protocol(Simplified) System Feature Map System Implementation Outline

An outline of the elections process as it pertains to the electronic voting system

A high-level map of features and functions for the new election system

An intricate discussion of how I would propose approaching this project from a design perspective

Download Download Download

 

After my presentation, we discussed the possible alternatives for implementing the system.

One particularly noteworthy development since the previous meeting was that I was approached by Dan O'Shea, a recently-graduated Princetonian who in the not-too-distant past had served in a role in the USG similar to my own.  Dan offered to build the system for $5000 and to deliver it on our timeframe.  From the beginning, I had been averse to the idea of having a student (or former student) develop the system because of concerns about impartiality and support (I suspect Dan will not want to be providing technical assistance on this system ten years from now).

However, the prospect of coming in well under budget and working with a developer who has had previous experience managing USG elections made this possibility very attractive.  I proposed the following two solutions to avoid the "ongoing support" dilemma:

Have Dan work in conjunction with OIT DAS to develop the system, so that DAS can then support the system.  This would allow Dan to develop the software and DAS to simultaneously give feedback on the development and develop an understanding for future support needs. Whenever changes are required for the system, hire a student to make the changes.  In the past, students have been compensated for helping develop and maintain USG web applications, and it has been successful.

However, neither of these two options seemed to make this work.  First, DAS cannot operate in a way to make idea 1 possible -- that's not something they are willing to do.  Second, the general consensus was that, paid or not, finding students to reliably maintain the code is something we do not want to have as an ongoing burden.

Next, Edward Freeland of the Survey Center mentioned that the university had recently purchased a license to use the Qualtrics survey platform.  According to Edward and Naila, Qualtrics is a new system they use to conduct surveys with which they have been very pleased.  Qualtrics is in use by other universities, companies, and the federal government, so it is a proven system.  In addition, Qualtrics is eager to accomodate our custom needs, as demonstrated by their assistance with previous research surveys conducted on campus.

Naila had previously mentioned this project to Qualtrics, who had said that they could develop the part of the system that allows candidates to submit their own information to the election for $2000.  This modification would simply extend the existing Qualtrics architecture to meet our needs.  This is a reasonable price for this component, so I suspect that we could implement most, if not all of the desired features and still remain within our original maximum budget of $15,000.

However, there is one significant caveat: if the Princeton Research Survey Center decides to switch survey providers, as they recently did, and abandon Qualtrics, the investment we made to get Qualtrics to work for us would become almost useless without Qualtrics.  Even if the USG wanted to continue using the Qualtrics system, the annual costs associated with licensing the system would be prohibitive.

Therefore, it seems that the system has fallen back in the hands of DAS, from which we began.  But before DAS will build the system from scratch, we must determine conclusively that there is no other option available for purchase, an "out of the box" system.  Matt Immordino will conduct the bulk of this this research and give a report at our next meeting.  In addition, the administrators included in the council reach out to our institutional peers through Ivy Plus, a communications network between univeristy administrators, to consider what other universites are using.  By comparison, I will reach out to the students at other universites through the Ivy Council, a similar student consortium established between universities.

We plan to have our next meeting during the week of June 22nd.

As a result of the recently conducted elections audit, the USG found an error in the 2012 senator elections this past year. Michael Yaroshefsky and Julie Chang had received the most votes, however the system reported that Julie Chang and Rebecca Lee had won the election.

Michael was given the opportunity to assume Rebecca's position as 2012 senator, however he declined this option to continue his role as the USG IT Chair. As a result, following constitutional procedures, USG President Connor Diemand-Yauman and Class of 2012 President Lindy Li held a series of interviews to appoint a new 2012 senator.

In the end, they decided to appoint Rebecca Lee back to her position as Class of 2012 Senator. So for the remainder of the year, Rebecca Lee and Julie Chang will be the Class of 2012 Senators.

In light of the frequent difficulties with previous elections, the USG has conducted an audit of all previous elections back through 2002. During this audit, an error was discovered in the class of 2012 senate election that took place this winter. The error caused votes cast for candidates Andreas Sakellaris and Michael Yaroshefsky to be disregarded when generating the final tally. OIT, who is responsible for the elections system currently used by the USG, confirmed that the algorithm that tallies votes had indeed malfunctioned. The original results processed by the system indicated that Julie Chang and Rebecca Lee were the top vote getters. After OIT corrected the malfunction, the system showed that Michael Yaroshefsky and Julie Chang had actually been the top two vote getters in that election.

Following this discovery, all involved parties were privately notified of the error. Michael Yaroshefsky could have accepted position as class of 2012 senator to which he was elected. However, he declined to accept this position, instead choosing to continue serving as IT Chair for the USG.  One of the two positions of class of 2012 senator is now vacant and will be filled according to the constitutionally-prescribed appointment process. 

Today, I had a meeting that included the registrar, Polly Griffen, and other associates in the Office of the Registrar.  Also joining us for the first time were members of OIT's Technology Consulting Services, Finance, Administration and Planning department.  The purpose of the meeting was to describe the expectations of the system in order to determine definitively how to proceed.  Namely, we will determine whether we can purchase an existing solution to meet our needs, or whether developing a custom system remains the best decision.

We began by developing a SIPOC value chain, determining the:

Suppliers Inputs Processes Outputs Customers (Receivers)

Going forward, I will be coordinating with Matthew Immordino of OIT to lay out a more specific list of requirements for the system.  Then, together we will contact vendors of elections software to see if they can meet our needs and at what price.  The original ballpark price OIT gave us was $7500 to $15000, so we are working to keep the cost under $15000.  Our next meeting is scheduled for June 8th.

Today I delivered a presentation to the USG Senate.  This was the second presentation regarding our effort to develop a new elections system to meet our needs.

During the presentation, I stressed the fact that USG elections are one of the two primary times during which almost everyone interacts with the USG (the other is lawn parties).  Every single election this year has been plagued by problems, many of which could have been prevented had there been some better elections management system in place.  This includes both the technical system and a detailed protocol.

This was the first time I announced my intention to develop alongside the  software an internal protocol.  From what I've seen while helping out during this past election, there needs to be a more clear understanding of who is responsible for certain parts of the election process.  It would be much more efficient if everyone could refer to a simple document that oulines everyone's responsibilities during the election cycle.

I then explained the expected price range of the system based on the estimate received from OIT during my previous meeting with them.  Since I expect the new system to last us 10 years (the current system was put together quickly and without any USG input, and it has lasted 7 years already), and there are 3 elections per year (freshman class, USG winter, USG spring), this works out to be 30 elections.  When you divide up the cost OIT gave us, that works out to be between $250 and $500 per election.  That's about inline with the cost of a study break.

You can download the presentation in PDF format here.

Today Dean Dunne and I met with Dave Herrington, the director of OIT's Departmental Application Services (DAS), and James Chu, the author of the current elections system and the soon-to-be author of the code for our next system.  DAS develops website applications for academic departments within the university.

During the meeting, we flushed out some special requirements for the system.  Dean Dunne and I reviewed the elections process and how the software comes into play.  We determined that it wouldn't be worth it to "fix" or update the current system.

Some critical features of the new system include:

Very friendly administrative interface with plenty of controls Direct link between candidate statements and the ballot Candidate management system built into the software Allowing individuals to submit referenda directly through the new system Enhanced security features to restrict access to the administrative panel Special features to detect malicious attacks

After our discussion, Dave mentioned that at the very least the project would require one month to complete.  Each month of labor will cost approximately $7500.  A more reasonable estimate would be two months, or $15000.  This was more than I had hoped, but given the complexity of the project, this seems to be a fair price.

From here, I will develop a comprehensive specification of goals.  We plan to then itemize these goals, and assign costs to each one.  Then we will determine, based on the costs, which particular goals should be attempted given the price and time constraints.

Today we had our first meeting with OIT regarding the elections system.  The purpose of the meeting was to trace the history of the current system and gain a little more information before the next election.  I learned that the current system we use was developed around 2002 when the Office of the Registrar decided to move away from using paper scantron ballots.  They asked OIT to develop a system.  OIT created the system, the Registrar approved it, and it went into service.  From my understanding, USG had minimal involvement in the process.  We then discussed a few minor technicalities of the upcoming spring USG election.

The Constitution and Voting Reform Working Group and the Information Technology Committee are working hard to devise new and improved means to ensure fair elections for the upcoming elections cycle. Through a collaborative effort involving the entire USG Senate, the working group promises tangible and reliable changes that will secure the USG voting process. Through significant adjustments in policy and the development of new technology, the USG believes that the elections process will run smoothly from now through future administrations.

Today I delivered my first (of what I assume will be a few) presentation to the USG senate regarding the new elections system idea.

During the presentation, I outlined a few of the problems I think the system has:

Custom coding the candidate statements (update: this appears to be incorrect.  There is an "automated" system in place, but it is very difficult to work with.  For one thing, the elections manager can't go in to edit candidate statements after candidates submit them.  Only the candidates can edit their own statements.) Miscommunication with the format sent to the Office of the Registrar for verification There seem always to be glitches in the system, such as people not being able to vote or candidates not showing up correctly The usg@ netID has access to view the election results, which could be a breach of security

I then outlined the mission of the project:

Mission: Our mission is to create a new election system that is secure, reliable, and manageable.  Secure: Allow access only to those who need it, only when they need it Reliable: Reduce the likelihood of interference in the elections prcess Manageable: Make managing elections as easy as posting to Facebook

You can download the presentation here.

Click a name to jump to the profile

President Connor Diemand-Yauman Vice-President Michael Weinberg Treasurer Trevor Martin Executive Secretary Jack Altman Undergraduate Life Committee Chair Arthur Levy Academics Chair Ben Lund Social Chair John Wetenhall Campus and Community Affairs Chair George Tsivin Communications Director Peter Tzeng Media Liaison Billy Hepfinger Student Groups Liaison Brian Jeong IT Committee Chair Michael Yaroshefsky 2010 Senators Christina Bortz Cole Morris 2011 Senators Helen Chen Derek Welski 2012 Senators Julie Chang Becca Lee U-Councilors -U-Council Executive Committee Representative -U-Council Chair Carter GreenbaumTiernan KaneJulia KaplanSteven LindsayBrian NoAlex PretkoKelly Roache Harry Schiff John-Allen Zumpetta

Connor Diemand-Yauman President

Connor Diemand-Yauman is a Psychology major who hails from the roaring metropolis of Chesterland, Ohio. Connor is busting at the seams with 2010 pride, having served as 2010 Class President for two and a half years before assuming his current role as USG President. During his term, Connor will make every effort to keep the USG's direction focused and relevant, addressing the most pressing student concerns that are likely to have the most far-reaching positive impact on the Undergraduate experience.

Michael Weinberg Vice-President

Michael is an ORFE major in the class of 2011, originally from Suffern, New York. On campus, Michael is also a leader in the Outdoor Program and is a conversation partner in the English Language Program. His favorite type of music is classic rock and favorite movie is Casablanca. His goals for the USG include increasing the efficiency and efficacy of the organization and fostering a close working relationship with the administration.

Trevor Martin Treasurer

Born in Atlanta, GA and a member of the great Class of 2011, Trevor is a prospective Molecular Biology or Physics major. When not staying up all night working, he likes to play violin, read the news, and juggle. As USG Treasurer, Trevor is working hard to make sure that the USG budget is used carefully and conscientiously, as well as serving on various working groups in the senate.

Jack Altman Executive Secretary

Hailing from St. Louis, Missouri, Jack Altman is a sophomore in the Economics Department. He hates foreign languages and loves swimming and video games. He hopes hope to aid the creation of an efficient and results-oriented student government.

Arthur Levy Undergraduate Life Committee Chair

Arthur is a junior History major from Boston, Massachusetts. In his spare time, he loves playing tennis and squash and watching Summer Heights High. His goal for Senate is to continue to work on issues that will improve student life on campus.

Ben Lund Academics Chair

Ben Lund is a Molecular Biology and Neuroscience major from Worcester, MA. When he's not working, he enjoys playing squash and baseball. Ben's goal as USG Academics Chair is to bring the concerns of the student body to the administration, particularly regarding P/D/F Policy and Academic Calendar Reform.

John Wetenhall Social Chair

John was born and raised in Rochester, NY and is a junior in the history department. John is a member of the sailing team and an Outdoor Action leader. He loves to ski and misses the snow and cold of upstate New York. As Social Chair, John hopes to bring more concerts to campus and make Princeton more social.

George Tsivin Campus and Community Affairs Chair

George Tsivin is a Senior in the Slavic Languages and Literature department, focusing on Linguistics. When he's not too busy, he enjoys playing tennis and researching genealogy. George is working on Lot 23 bike racks, Taste of Prospect, and Alcohol Initiatives. George hopes to foster healthy "town and gown" relations for this year and many years to come.

Peter Tzeng Communications Director

A proud member of the class of 2011, Peter is a Woodrow Wilson School major from Cherry Hill, New Jersey. He enjoys running, playing ultimate frisbee, learning languages, traveling, and blasting 90s music. In the realm of student government, Peter hopes to ensure a clear and concise presentation of information to the student body.

Billy Hepfinger Media Liaison

Billy is a senior in the comparative literature department. He comes from Pittsburgh, PA, and keeps a photo of Troy Polamalu under his pillow. Billy performs with a number of groups around campus, including the Nassoons, the Triangle Club, Theatre Intime, PUP, and Funkmaster General, and is also a member of Tower Club. His work ethic will decline tremendously when the final season of LOST starts in January. As Media Liaison, Billy hopes to foster more transparent, well-articulated communication between the USG and the student body.

Brian Jeong Student Groups Liaison

Brian Jeong, class of 2011, is from New York City. On campus, he is a proud member of diSiac Dance Company and plays for Club Basketball and Princeton Taekwondo. As Student Groups Liaison, Brian will work to foster dialogue among student group leaders, the USG, and ODUS.

Michael Yaroshefsky IT Committee Chair

A member of the class of 2012 from Wayne, New Jersey, Michael is a prospective Operations Research & Financial Engineering major. He enjoys working with other people, learning about technology, and playing tennis. He has been making websites since 2001 and serves as president of MikeYaroSoft, Inc, his website design firm. This year, Michael hopes to improve the way the USG uses technology to communicate and to achieve its goals.

Christina Bortz Class of 2010 Senator

Christina is a senior Politics major, with a focus on International Relations, and hails from Emmaus, Pennsylvania. Besides her involvement in USG, she is a co-captain on the varsity field hockey, a residential college advisor in Rocky, and co-VP of National Society of Collegiate Scholars, Princeton Chapter. She enjoys traveling and loves meeting new people.  Her goal this year is to serve to student body by contributing to focused initiatives that seek to improve the quality of student life - academic, socially, and athletically.

Cole Morris Class of 2010 Senator

Hailing from Hingham, MA, Cole Morris is a junior in the Woodrow WIlson School. He likes logic puzzles, squash, and public safety officers. He puts the Student back into Undergraduate Student Government and is generally very attuned to the USG's internal morale. His picture is sexy.

Helen Chen Class of 2011 Senator

Helen is from the far and exotic place of Roxbury, New Jersey. Things she loves: napping, frist salads, carbohydrates, napping Things she hates: non-frist salad vegetables, doing laundry, wearing pants Helen hopes to help make USG more action oriented and transparent.

Derek Welski Class of 2011 Senator

Derek hails from the exotic town of far-off Princeton, NJ and resides in the lovely Rockefeller College. He enjoys traveling, skiing, and sitting down and having a good conversation. As far as the USG is concerned, any meaningful and practical policy requires a glimpse into the perspective and first hand experience. Just as much as the students need the USG to pass policies, the USG needs the students by its side and providing it with ways to improve Princeton; from the social to the academic and communal. Derek hopes that the USG and the students together will make this a more transparent and vocal USG.

Julie Chang Class of 2012 Senator

Julie hails from the great unincorporated area of Bethesda, Maryland. She is considering either History or Comparative Literature as a major. In her spare time, she enjoys playing club sports, watching Damages, and listening to Tuvan throat singing. Her goal as student senator is simple: to maintain an open dialogue with her constituents, and to proactively address issues concerning Princeton undergraduates.

Becca Lee Class of 2012 Senator

Becca is from South Burilngton, Vermont and is considering history, politics, and psychology as potential majors. She enjoys taking pictures and watching movies and she is also a member of the club lacrosse team. Her goals this year are to lower textbook prices, encourage civic engagement on campus, and get some sort of a postal stamp vendor in Frist.

Carter Greenbaum U-Councilor

Carter is a Sophomore Politics major from Newport Beach, California, pursuing a certificate in the creative writing department. He is a varsity member of the men's lightweight crew team. He is incredibly excited to kick off his first term on the USG pursuing initiatives for the equal treatment of all students on campus, and creating a closer rapport with the administration on policy matters to help represent the student body, while making the "Princeton experience" better for every one.

Tiernan Kane U-Councilor

Tiernan is a junior from Fishers, Indiana.  A Classics major, he is interested in politics, history, and philosophy. On the USG, he wants to set achievable goals and then achieve them.

Julia Kaplan U-Council Executive Committee Representative

Julia is from South Brunswick, NJ and is a Woodrow Wilson School major in the great class of 2011. Her interests include politics, music, and attempting to become fluent in Spanish. Julia's goal on USG is to accurately represent the student voice, working with other USG members to find innovative ways to improve the undergraduate experience.

Steven Lindsay U-Councilor

Steve, from West Milford, NJ is a prospective Politics major whose primary interest is constitutional theory and interpretation. On campus, Steve is involved with American Foreign Policy magazine, Princeton Model Congress, and the James Madison Program for American Ideals and Institutions. In his free time, he enjoys golf and playing the bass guitar. As a U-Councilor, Steve hopes to promote fiscal responsibility, electoral fairness, and constitutional reform. He also hopes to raise awareness in issues dealing with mental health and the quality of life on Princeton's campus, and to address those issues with care and precision.

Brian No U-Council Chair

Brian is a third-term U-Councilor and a member of the Class of 2010. He is a Politics major and hails from Denver, Colorado. He is also president of the University Press Club. His primary goal on the USG is to serve as an effective voice for student issues, including sustainability, housing, and student-professor relations.

Alex Pretko U-Councilor

Alex Pretko is a sophomore from Kingston, PA concentrating in economics. When not sleeping (which is far too often for his tastes), he enjoys singing in the Princeton Glee Club, speaking foreign languages, and the occasional marathon session with his Xbox 360. His goal for the USG is to effectively address the concerns of and bring about the changes desired by the student body.

Kelly Roache U-Councilor

Kelly is a prospective Woodrow Wilson School major with a Near Eastern Studies certificate from the Jersey Shore. Aside from USG, she enjoys being active in the International Relations Council, Forbes College Council, feminist blog /Equal Writes/, Princeton University Gospel Ensemble, and several religious and political groups. She looks forward to increasing USG's accessibility and working on several promising projects this semester to enhance civic engagement and student life on campus.

Harry Schiff U-Councilor

Harry is a '10 Psychology Major from Montreal. His main goal is attempt to shape university policy in such a way that it does not interfere with the needs and desires of a wide range of students. This means that new policy should only address issues that are clearly and widely agreed to be problems and solutions that aim to directly address those problems, while minimizing other side-effects.

John-Allen Zumpetta U-Councilor

John-Allen is a sophomore Politics major from West Virginia. In his spare time he likes playing soccer, swimming, and listening to classic rock. He hopes to improve the efficiency of USG and produce tangible results that all students will be able to benefit from.