Join us for the San Francisco Net Tuesday on September 9:
Involver: How Nonprofits Can Create Video Campaigns for Social Networks.
Vote counting process
1. Exported the ballot ID numbers and vote choices 1-10 for all submitted ballots to a CSV file and saved as an Excel worksheet. Vote choices were exported as project i.d. numbers, rather than project names, so all calculations were performed “blind”, without knowing which project each i.d. number corresponded to.
2. Created a formula to search the Excel worksheet for any ballot that contained multiple votes for a single project, and removed all these ballots.
3. Generated a count of each value (i.e. project i.d.) and sorted the counts by descending frequency.
4. Identified the project titles for the top 30 vote-getters.
5. Compared our winners list to the list generated by CompuMentor, and confirmed that we had the same top 21 projects.
Validation process: voter authentication
The purpose of this process was to ensure that the voting process was not manipulated by mass voting by a single user using multiple e-mail addresses and usernames.
The steps we took were:
1. Exported the log of all ballots added or updated on NetSquared.org as a CSV file and created an Excel workbook with all ballots.
2. Deleted the ballot updates so we had a table listing all ballots added, along with the IP address, email address, timestamp and user name of the ballot’s creator (but not the actual vote choices).
3. Searched the table for any ballot that shared an IP address with another ballot, and copied all these ballots with duplicate IP addresses to another worksheet.
4. Reviewed the list of ballots voted from common IP addresses to identify any large blocks of IP addresses, which might suggest someone voting repeatedly from the same machine.
5. Manually reviewed each block of repeating IP addresses and looked at the associated e-mail addresses, looking for any anomalous patterns. In most cases the blocks of repeating addresses corresponded to a single organization with multiple voters and email addresses.
6. Identified several large blocks of IP addresses that shared a near-identical set of usernames, and concluded from the pattern of IP addresses, timestamps and usernames that 36 ballots were almost certainly cast by the same individual.
7. Removed these 36 ballots and recalculated the vote results, and confirmed that the same 21 projects achieved winning numbers.
Conclusion: While a single user likely voted 36 times for a single project, this did not affect which projects made the top 21 list. There was no evidence of any other user engaging in mass voting.
Validation: CompuMentor
The purpose of this process was to assess whether enforcing the rule against voting multiple times for the same project (which was technically possible even though it was against the rules) affected the outcome of the vote. Since people may have voted multiple times for a single project out of misunderstanding rather than ill intent, we were concerned about the potential impact of invalidating their ballots.
1. Ran PHP script that was programmed to count all ballots, but to remove any duplicate votes.
2. Generated a list of the top 40 projects based on this vote count, which counted the votes from ballots that contained multiple votes for the same project, but only counted a single vote for any one project on any one ballot.
3. Manually reviewed all ballots and identified any ballots with multiple votes cast for a single project.
4. Compiled a count of all votes cast by invalid ballots (i.e. ballots with multiple votes cast for single project).
5. Subtracted invalid votes from project totals for top 40 projects.
6. Confirmed that the same projects placed in the top 21, whether the invalid ballots were counted or not.
Conclusion: While some voters cast multiple votes for a single project (possibly due to misunderstanding rather than ill intent), the results were the same whether or not these ballots were counted.