From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D0730158013 for ; Sat, 28 Aug 2021 19:08:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8962FE0870; Sat, 28 Aug 2021 19:08:41 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6367AE0855 for ; Sat, 28 Aug 2021 19:08:41 +0000 (UTC) Message-ID: Subject: Re: [gentoo-project] [pre-GLEP] Secrecy-respecting voting mechanism for Gentoo projects From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-project@lists.gentoo.org Date: Sat, 28 Aug 2021 21:08:36 +0200 In-Reply-To: References: Organization: Gentoo Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: d0bb1efc-e050-46e5-b5ef-b778c3be7fe2 X-Archives-Hash: 10aabadd72a6fb624f55265b41fe02d4 On Sat, 2021-08-28 at 15:01 -0400, Aaron Bauman wrote: > On Sat, Aug 28, 2021 at 12:30:15PM +0200, Michał Górny wrote: > > Hi, > > > > Please review the following pre-GLEP. > > > > --- > > GLEP: 9999 > > Title: Secrecy-respecting voting mechanism for Gentoo projects > > Author: Michał Górny > > Type: Standards Track > > Status: Draft > > Version: 1 > > Created: 2021-08-27 > > Last-Modified: 2021-08-27 > > Post-History: 2021-08-27 > > Content-Type: text/x-rst > > --- > > > > Abstract > > ======== > > > > A new voting system is devised with the aim of providing a single voting > > system for all Gentoo elections and votes. Automation is used to > > eliminate the human bottleneck in processing the elections. Votes are > > submitted via random identifers, and the identifiers are sent to voters > > via encrypted e-mail to protect the vote secrecy. E-mail is used to > > enable non-developer voters to participate. > > > > > > Motivation > > ========== > > > > The votify/countify tooling used to run Gentoo elections dates back > > to 2005. While it still serves it purpose, it has grown antiquated > > and is facing a few problems that are discouraging the developers from > > using it. These are: > > > > The problems with the current tooling include: > > > > 1. The elections require a lot of manual setup and attention. This is > > causing noticeable delays and can raise doubts about the validity > > of elections. For example, voters can still submit or modify votes > > after the deadline until the infra official collects them. > > > > Given what we have seen in the security election this year, what > determines *who* can start an election? Maybe some clarity in GLEP 39? This is outside the scope of this GLEP. It's about providing a tool, not telling how projects select leads. That's really in scope of GLEP 39 indeed. > > At this point, votify is practically used only for the Council > > and Trustee elections. The late attempts of using it for the Base > > System and Security project elections have resulted in a lot of > > frustration from the developers participating. The vast majority of > > project elections are currently run using third-party services or plain > > mail votes. > > > > I am not aware of anyone from the security team having issues with > this... would you please expound on the issues of use? > The complaints I've seen were primarily because of how long it took for Elections team to publish results. I suppose it was in comparison with Helios where the results are immediately available. -- Best regards, Michał Górny