[cabf_governance] Initial Thoughts on Ballot Method Improvements

[Jos Purvis (jopurvis)]

I’d just like to take a moment to apologize for that car-crash of a final sentence. Clearly, I have issues with addiction to the use of the colon. :)

 

-- 

Jos Purvis (jopurvis at cisco.com)

.:|:.:|:. cisco systems  | Cryptographic Services

PGP: 0xFD802FEE07D19105  | +1 919.991.9114 (desk)

 

 

From: Govreform <govreform-bounces at cabforum.org> on behalf of "Jos Purvis (jopurvis) via Govreform" <govreform at cabforum.org>
Reply-To: CA/Browser Forum Governance WG List <govreform at cabforum.org>
Date: Thursday, 20 April, 2017 at 15:45 
To: Virginia Fournier <vfournier at apple.com>, CA/Browser Forum Governance WG List <govreform at cabforum.org>
Cc: "Jos Purvis (jopurvis)" <jopurvis at cisco.com>
Subject: Re: [cabf_governance] Initial Thoughts on Ballot Method Improvements

 

Hi Virginia,

 

I agree: these are good topics to bring up at the next meeting; I just wanted to throw them out there to get some initial thoughts on paper. While I agree that the Microsoft case was unusual, I feel like as long as we are relying on a fundamentally finicky protocol like SMTP for doing our voting, we do need to have some language in the Bylaws that specifies what to do when there is a dispute about the outcome of a ballot. We got lucky in this case that the group decided declaring a “do-over” was the right strategy, but if there had been long-standing dispute over the correct way to resolve the problem the Bylaws as they stand wouldn’t have helped much.

 

All that said, I very much agree with keeping it simple: the least amount of process necessary to resolve a problem is definitely the way to go: if we can just create a blanket “if there’s a dispute or problem we do thus and so” statement and move on, I think that would suffice. :)

 

Thanks,

 

Jos 

 

-- 

Jos Purvis (jopurvis at cisco.com)

.:|:.:|:. cisco systems  | Cryptographic Services

PGP: 0xFD802FEE07D19105  | +1 919.991.9114 (desk)

 

 

From: <vfournier at apple.com> on behalf of Virginia Fournier <vfournier at apple.com>
Date: Thursday, 20 April, 2017 at 15:35 
To: CA/Browser Forum Governance WG List <govreform at cabforum.org>
Cc: "Jos Purvis (jopurvis)" <jopurvis at cisco.com>
Subject: Re: [cabf_governance] Initial Thoughts on Ballot Method Improvements

 

Hi Jos, 

 

These are interesting ideas we can explore at the next meeting.  However, I really think the Microsoft voting situation was really a corner case that we should not expend a lot of time trying to cover.  As soon as we cover that one, it will likely never happen again, and next time it will be something else.  I agree we could address a general situation where the vote is unclear or not received, and what to do in that case.  

 

We should also keep it simple - the less language we have, the lower the chance of disagreement on something.  ;-)










Best regards,

 

Virginia Fournier

Senior Standards Counsel

 Apple Inc.

☏ 669-227-9595

✉︎ vmf at apple.com

 

 

 

 

 

On Apr 20, 2017, at 11:41 AM, Jos Purvis (jopurvis) via Govreform <govreform at cabforum.org> wrote:

 

In light of the recent issues with ballot 194, I've been pondering what kinds of changes to the bylaws would help sort this out more easily next time. I've come up with a couple problems that look like they need solving and some proposals for solving them; since I'm pretty sure we'll be asked to incorporate these into our suggested bylaw changes, I thought I'd workshop them here first and see what people thought before venturing forth onto the public list with them.

 

For each one of these, I’ve got a basic problem statement (numbered), and then some possible solutions (the letters); the lettered options are intended to be mutually exclusive solutions to the same problem. I’m using XXX as a placeholder here for some numeric value to be determined later—I wanted to think about solution processes first and not get hung up on 51% vs. 67%.

 

Problems:

1)       A ballot's voting results are, for whatever reason, ambiguous or cannot be satisfactorily determined based on the tally of indisputably valid votes.

Potential solutions:

a)      If the vote tally cannot be clearly sorted to the written agreement of XXX% of the membership within XXX days after completing the voting period, the ballot shall be declared failed and no change shall be instantiated from it at that time. The ballot may be re-proposed by its authors at any time thereafter, with or without modification.

 

b)      If the vote tally cannot be clearly sorted to the written agreement of XXX% of the membership within XXX days after the voting period, the vote shall be declared invalid. A new standard voting period of 7 days shall be declared by the Chair to start within 7 days after the ballot is declared invalid. This vote shall be conducted as a normal ballot vote. Should this vote also turn out invalid, the ballot shall be declared failed and no change shall be instantiated from it at that time. The ballot's authors are free to re-propose the ballot under a new ballot number at any time thereafter, with or without modification.

 

2)      A member organization posts their vote on a ballot within the voting window but the vote does not appear on the public mailing list for one reason or another.

Potential solutions:

a)      If the vote does not appear on the public mailer but can be independently verified by at least XXX other members to have been sent within the voting window (such as by CCing additional members individually), the vote shall be declared valid and tallied in the voting totals. In the event the vote cannot obtain XXX endorsers as to its validity, it shall be declared invalid and not tallied with the voting totals.

 

b)      If the member representative who posted the vote is subscribed to the mailer, then the Chair and Vice-Chair shall independently examine the email envelope from the failed vote. If the email envelope headers clearly indicate that the email was sent (released from the sender's email client to the first-hop email server) prior to the close of the voting period, the vote shall be counted as valid and tallied in the voting totals. If the member representative who posted the vote is not subscribed to the mailer, the vote shall be automatically declared invalid. In this case, the vote shall not be counted among the tally of voting totals, regardless of whether others in the forum received a copy of the vote within the voting period.

Couple thoughts here:

·         Actually, I think the "if the representative isn't subscribed, that vote doesn't count" rule should be a standard insertion no matter what we choose here. I don't like the precedent of organizations just picking random people to send their votes whether or not they're subscribed to the list. As we've seen, it causes higgledy-piggledy.

·         It’s tempting to declare that if a ballot doesn’t appear on the public mailer it simply doesn’t count, but this means companies will need to allow an extra buffer window before the end of the voting window in order to be sure they can re-submit if their vote does not appear. That might be OK with everyone (it does encourage voting early!), but it’s effectively reducing the size of the voting window. Additionally, we should still have a procedure to cover the contingency of a member having persistent problems with vote submissions during a window (e.g. if the public mailing list software begins rejecting their email domain as SPAM).

·         One thing that should not be a solution here is voting by proxy or permitting the “I received a copy of their vote, therefore it counts”. I deliberately tried to avoid that, as I don’t like establishing the precedent that organizations can vote through someone else (too much room for error). Option (a) was as close as I was willing to come, and it would ideally involve collusion among multiple members to subvert.

 

3)      The public mailing list is unavailable or significantly delays posting messages, affecting the Forum as a whole or a large part thereof.

Potential solutions:

a)      The Chair may, at the Chair’s discretion, extend the voting period for a ballot due to significant availability issues. To make this fair, this would entail extending the period for ALL members, so members who had already voted could change their votes during this window. However, no further discussion about the ballot could ensue during the extension period, to avoid 'extended campaigning'. The Chair would need to declare an extension of the voting period BEFORE posting a tally of the votes or declaring the ballot complete, and would need to declare such an extension within XXX hours of the completion of the voting window, to avoid the appearance of declaring extensions to change the outcome.

 

b)      The Chair may, with written agreement of XXX% of membership, designate an alternate list or forum such as the management list or another public forum for the voting to take place. This could ONLY be done due to an extended outage or issue with the existing public mailer. The voting window would then be re-started from the beginning, and would have to take place ONLY on this new location (to avoid confusion). Votes already submitted to the standard CABF public mailer would need to be re-submitted to the new location. Following the re-establishment of the official mailing list, the Chair and Vice-Chair would jointly be responsible for re-posting copies of all voting tallies and any other significant discussion items such as ballot changes to the official mailing list within XXX days.

 

 

-- 

Jos Purvis (jopurvis at cisco.com)

.:|:.:|:. cisco systems  | Cryptographic Services

PGP: 0xFD802FEE07D19105  | +1 919.991.9114 (desk)

 

_______________________________________________
Govreform mailing list
Govreform at cabforum.org
https://cabforum.org/mailman/listinfo/govreform

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/govreform/attachments/20170420/b3a13db9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4072 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/govreform/attachments/20170420/b3a13db9/attachment-0001.bin>