Harlan Lieberman-Berg <hlieberman@setec.io> writes: > On 3/1/22 23:13, Harlan Lieberman-Berg wrote: >> Hello everyone, >> >> I propose the following ballot option for the current GR: >> >> Rationale >> ======== >> While I agree that there are some votes which, due to their nature, >> may be so controversial that the potential for a person's votes to be >> publicly revealed may cause them to change their vote (or opt out of >> the election), even among divisive GRs, few rise to that level of >> controversy: the RMS GR and the systemd GR being two recent examples >> which have provoked ire. >> >> There is something which fundamentally distinguishes the kind of >> voting that Debian does from that of a private institution or group, >> where minutes and votes are typically kept out of public view: Debian >> serves a larger community than the members of the institution. In >> that sense, we are more similar to a public body than a private >> membership. >> >> Our Social Contract makes this distinction clear: when it says that we >> will not hide problems, it immediately emphasizes that the bug >> database will be open for public view at all times. Taking the step >> to make a particular vote secret should require us to stop and >> carefully weigh the costs to the larger community. >> >> I hope this option better strikes the balance between the aspirations >> of public visibility and the occasional, pragmatic need for secrecy. >> >> Ballot Option >> ========== >> The changes are available at: >> https://salsa.debian.org/hlieberman/webwml/-/commit/82729d07aba7dd7ac641f7e4a87178f34b23efca >> >> A diff follows (the word diff is very confusing, so I've omitted it): >> >> diff --git a/english/devel/constitution.wml >> b/english/devel/constitution.wml >> index 41cb9dfbd80..7924992d3a7 100644 >> --- a/english/devel/constitution.wml >> +++ b/english/devel/constitution.wml >> @@ -226,12 +226,15 @@ earlier can overrule everyone listed >> later.</cite></p> >> >> <li> >> <p> >> - Votes are taken by the Project Secretary. Votes, tallies, and >> - results are not revealed during the voting period; after the >> - vote the Project Secretary lists all the votes cast. The voting >> - period is 2 weeks, but may be varied by up to 1 week by the >> - Project Leader. >> + Votes, tallies, and results are not revealed during the voting >> period. >> + After the vote, the Project Secretary lists all the votes >> cast, unless >> + either one of the following is true: >> </p> >> + <ol> >> + <li><p>The vote is for a leadership election as defined in >> §5.2.</p></li> >> + <li><p>At least 4K Developers have sponsored any single ballot >> option >> + which says the votes will be kept secret.</p></li> Does this not force people that would like to keep their vote secret to publish that fact in order for it to happen (which might well hint strongly at how they are likely to vote)? In reaction to that flaw I suspect you'd then end up with a bunch of public-spirited folk suggesting that option for every vote, in order to cater to a presumed need for privacy by others. If that's the case we could save everyone the effort by just making all votes secret. How about people being able to request a secret ballot in private, by asking the secretary, who would keep a tally of requests and announce whether the vote was to be secret before voting started? BTW I had been persuaded that the published-only-internally option was not really good enough by subsequent discussion, which is why I've not proposed such an amendment, but perhaps the combination of published-only-internally with option-to-go-secret would actually be worth having as a ballot option. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] HANDS.COM Ltd. |-| http://www.hands.com/ http://ftp.uk.debian.org/ |(| Hugo-Klemm-Strasse 34, 21075 Hamburg, GERMANY
Attachment:
signature.asc
Description: PGP signature