[PDB-gov] BigPulse effort

Chris Caputo secretary at peeringdb.com
Tue Nov 10 18:03:51 PST 2015

Some items (most significant at bottom) re BigPulse...


Are people okay with the voting method being Single Transferable Vote 

   (CGP Grey take on STV)

At present there are 12 candidates for 5 seats.  STV means that when you 
vote, you will be able to rank the candidates, and BigPulse will handle 
the transfer of votes as warranted by STV.  The idea with STV is that 
votes are not wasted, and voters can vote for who they think best, rather 
than strategically.


For the Anonymity setting, I have configured things so that I can not see 
the votes, but voters may change them.  This is described at:


If there is a thought that you all want me to be able to see the votes, 
for some kind of auditing purpose, please speak up.  I'm cool with 
trusting BigPulse if you all are.

Along with the anonymity setting, I have configured BigPulse so that when 
the voting is happening, I will be able to see what organizations have 
voted, but I will not be able to see their votes or the candidate totals.


Since we are now using BigPulse, I've made it so the names on the ballot 
rotate, rather than being alphabetical by last name, as I've previously 


PeeringDB draft docs state that a Member is an organization with a 
PeeringDB account which also has individual or role representative(s) 
subscribed to this mailing list (pdb-gov).

In many cases, there are multiple representatives of the same organization 
subscribed to pdb-gov.

The way BigPulse works is that a voting account is set up for each single 
voter, and this account has at most two email addresses associated with 

Each voting account will be emailed a ballot that contains a unique URL 
which enables login to the voting process.

Thus we need to make sure each organization has only one vote, by creating 
only a single voting account for each potential voting organization.

Given the above, I think we're going to need to do one of two things:


  - Use scripts (much of which Matt has already created, involving no 
    doubt several hours to do so), to go from the list of subscribers to 
    pdb-gov to organization records in the PeeringDB database.  And from 
    there email the first Policy email address in a given record.  If no 
    Policy entry, fallback to whatever email is available.  There may be 
    some manual intervention here, such as to choose peering@ over an 
    individual email.

    - As I was writing this, Matt emailed to say is handling this issue, 
      reducing down to a single email address per organization.  So we may 
      be fine here.


  - Send a simple survey to the addresses on this list in which folks who 
    want to vote, respond saying they are the voter for their 
    organization.  (Organizations to work this out internally.)  I then 
    check PeeringDB to confirm they are associated with an active account, 
    and then create the BigPulse account for them, so they can get the 
    email with the voting URL when voting starts.  Role addresses such as 
    peering@ can be used.

    - Even if we go with the first option, some surveying may be needed 
      for those email addresses that don't obviously match up with an 
      organization in PeeringDB.  But the thing to be careful about here, 
      is folks claiming to represent an organization when they aren't 
      emailing from the organization's domain name.  Should we just 
      declare that ballots can only go to the domain name of an 
      organization they represent?

Other options?


More information about the Pdb-gov mailing list