I second the ballot option quoted below. However, to generate further discussion, I do agree with Judit [1] that 4K seems like a high bar. In a general sense, if the bar is too high then the result might be indistinguishable from not allowing secret votes at all. Of course the opposite could be true as well - if the bar is too low, then it might be indistinguishable from having all votes be secret. Is 4K too high? Or is it high but still OK? Would K or 2K be more appropriate? Or would those be too low? I honestly don't know. If the goal is to default to openness, but still allow secret votes for sensitive topics, how do we choose the threshold that is best suited to that? Best regards, Bill [1] https://lists.debian.org/debian-vote/2022/03/msg00016.html On Tue, Mar 01, 2022 at 11:13:03PM -0500, Harlan Lieberman-Berg wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > 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> > + </ol> > </li> > > <li> > > > - -- > Harlan Lieberman-Berg > ~hlieberman > -----BEGIN PGP SIGNATURE----- > > iQKTBAEBCgB9FiEELyAgabIlUqb16FUfGikbTg3OS1cFAmIe7pJfFIAAAAAALgAo > aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDJG > MjAyMDY5QjIyNTUyQTZGNUU4NTUxRjFBMjkxQjRFMERDRTRCNTcACgkQGikbTg3O > S1d5zQ/9F9rMHgeOnEyXWkZ1gIAabwjzY5IedPkoEGECaGz9uiYA446J/Q+jH5V6 > blDNcTmy3VL8YxrPJ1NKhwYpF7SCL0QxUnCXiFtp5UFYzCiDWqWGHM4UbqPMZxox > 8Z3/oDu7W5N8aa9GHSsL0f6aHtxBHxIS/CnA+wtOIGuGEpHQRxGhqQ0P17pbPkDn > bOMbPC9x2Sve2bwzZ4hlvCySRGVorwKNWsvjZ7LWCc5k6a1ZLBYFQK065J6l17NN > 6+rEBZ8yJ6UHnQ9wH1Y7loM8B4Z35qgf6MwXyeqMYHSRSrmfAc2uIp/EL4FStig2 > 4wWiNEyN6QuWkR75Tr3ZSNC+2NF3ptRmM+gc2nBWhz6Zx+yVm5JmvRHkGQfsTrRD > 0NtVTflHIOHGsFHYj16IHmC1Xvu/9OHvf4bQumahIG88Rz58Zgsi965FaDTRn5di > FtAxKoxsqzvKAe0OJkUHOnSVnv3w95UNg0uco5tgbUmDYISlFYNTHav0gL1EQBR2 > GeNYNlJP6zlFEu6uxZuXlfv3BLNvQ4Yc2miE9Rv14bKEd1QizPVUGpX5YR8a89Ph > QF2tSdy62MFqRrV9VKmheEnNb2uNsttFJci6ZBjci32zP6mMMFEgUuvgfl2CaMbG > MUBi7dtjYkoL3IQuj+OsF5VKZLq2ERJhIDf8mogzetUWNT8aQVo= > =5e/l > -----END PGP SIGNATURE----- > -- GPG: 5CDD 0C9C F446 BC1B 2509 8791 1762 E022 7034 CF84
Attachment:
signature.asc
Description: PGP signature