Résolution générale : secret du vote

Calendrier

Période de débat : 23 février 2022 11 mars 2022
Période de vote : dimanche 13 mars 2022 00:00:00 UTC samedi 26 mars 2022 23:59:59 UTC

Déposant de la proposition A

Sam Hartman [[email protected]] [texte de la proposition] [amendement]

Parrains de la proposition A

  1. Russ Allbery [[email protected]] [message]
  2. Steve McIntyre [[email protected]] [message]
  3. Bill Blough [[email protected]] [message]
  4. Filippo Rusconi [[email protected]] [message]
  5. Sean Whitton [[email protected]] [message]
  6. Pierre-Elliott Bécue [[email protected]] [message]

Proposition A

Cacher l'identité des développeurs votant à un scrutin particulier

Raison

Durant le scrutin pour la résolution générale GR_2021_002, plusieurs développeurs ont déclaré qu'ils n'étaient pas à l'aise pour voter, parce que, selon la procédure en vigueur, leur nom et le classement exprimé seraient publics. Un certain nombre de participants à la discussion pensaient que nous obtiendrions un résultat des élections qui refléterait plus fidèlement la volonté des développeurs si nous ne publiions pas les noms associés à chacun des votes à la feuille de scrutin. Plusieurs personnes pensent que les votes de classement sans les noms des développeurs apporteraient quand même des informations publiques précieuses.

Cette proposition s'appliquerait à toutes les élections comme les élections du chef de projet. En même temps, cela assouplit l'exigence pour le secrétaire de conduire un vote par courriel. Si l'obligation de vote par courriel n'existe plus, une expérience est prévue au moins avec le système de vote Belenios. Belenios peut fournir un meilleur secret de vote et un système de vote basé sur le web plus facile que notre approche actuelle par courriel. Si cette proposition passe, adopter une telle alternative devrait nécessiter un soutien suffisant dans le projet, mais ne devrait pas avoir besoin d'un autre amendement de la constitution.

Cette proposition accroît notre dépendance au pouvoir existant du secrétaire de décider comment les scrutins sont menés. L'absence de mécanisme pour outrepasser les décisions du secrétaire sur comment nous menons nos votes n'a pas été un problème jusqu'à présent. Néanmoins, si nous allons dépendre de ce pouvoir pour réfléchir à des questions comme de savoir si le projet a atteint un consensus pour adopter un mécanisme de vote alternatif, nous avons besoin d'un mécanisme de contestation. Aussi, cette proposition introduit un tel mécanisme.

Résumé des modifications

1) L'identité de l'électeur émettant un vote particulier n'est pas rendu public.

2) Le vote par courriel n'est pas obligatoire.

3) Clarification du fait que les développeurs peuvent remplacer le secrétaire à tout moment.

4) Prévoir une procédure pour outrepasser la décision du secrétaire du projet ou de son délégué. Outrepasser la décision qu'une majorité qualifiée est requise ou outrepasser la décision du résultat du scrutin requiert une majorité à 3 contre 1. La présidence du comité technique décide qui conduit ce type de vote.

6) inscrire dans le code que notre système d'élection doit permettre une vérification du résultat du scrutin et doit permettre aux développeurs de confirmer que leur bulletin est inclus dans la liste des bulletins.

Résolution générale

Les développeurs prennent la résolution de procéder aux modifications de la constitution Debian incluses dans le commit Git ed88a1e3c1fc367ee89620a73047d84a797c9a1d. À partir du 23 février 2022, ce commit peut être consulté à l'adresse [https://salsa.debian.org/hartmans/webwml/-/commit/ed88a1e3c1fc367ee89620a73047d84a797c9a1d

Pour des raisons de commodité, une liste des modifications est incluse ci-dessous. Si la liste des modifications diffère du commit, c'est le commit qui fait autorité. [Note du traducteur : les numéros de ligne du diff sont ceux du texte original en anglais.]

@@ -179,9 +179,27 @@ ne peuvent pas tous outrepasser les décisions de tous ceux qui sont cités
ensuite.</cite></p>
  </li>

  <li>
    <p>Désigner un nouveau secrétaire [-en cas de désaccord entre-].
    {+Dans le cas normal ( §7.2) où+} le chef de projet et le secrétaire
    [-auquel cela incombe-] {+sont d'accord sur le nouveau secrétaire, ce
    pouvoir des développeurs n'est pas utilisé+.</p>+}
  </li>
  {+<li>+}
{+    <p>Outrepasser une décision du secrétaire du projet ou de son+}
{+    délégué.</p>+}

{+    <p>Outrepasser la décision sur quelle majorité qualifiée est+}
{+    requise pour une option de vote particulière ou outrepasser la décision+}
{+    sur le résultat d'une élection requiert un accord des développeurs+}
{+    par une majorité à trois contre un. La décision sur la majorité requise+}
{+    pour outrepasser une décision du secrétaire n'est pas sujette à+}
{+    annulation.</p>+}

{+    <p>Le président du comité technique décide qui agit en tant que+}
{+    secrétaire pour une résolution générale pour outrepasser une décision+}
{+    du secrétaire du projet ou de son délégué. Si la décision n'est pas+}
{+    prise par le président du comité technique, le président du comité peut+}
{+    agir lui-même comme secrétaire. La décision de qui agit comme secrétaire+}
{+    pour ce type de résolution générale n'est pas sujette à annulation.</p>+}
</ol>

<h3>4.2. Procédure</h3>
@@ -228,9 +246,10 @@ ne peuvent pas tous outrepasser les décisions de tous ceux qui sont cités
ensuite.</cite></p>
    <p>
    Les bulletins sont reçus par le secrétaire du projet. Les bulletins, les
    contrôles et les résultats ne doivent pas être révélés pendant la durée du
    scrutin ; après le scrutin, le secrétaire du projet liste tous les
    contenus des bulletins {+avec suffisamment de détail pour que chacun+}
    {+puisse vérifier le résultat de l'élection à partir de la liste des+}
    {+bulletins. L'identité d'un développeur émettant un vote particulier+}
    {+n'est pas rendue publique, mais les développeurs reçoivent une option+}
    {+pour confirmer que leur bulletin est inclus dans la liste des+}
    {+bulletins.+}
    La période de scrutin est de 2 semaines, mais elle peut être
    modifiée d'au plus une semaine par le responsable du projet.
    </p>
  </li>

@@ -247,7 +266,7 @@ ne peuvent pas tous outrepasser les décisions de tous ceux qui sont cités
ensuite.</cite></p>
  </li>

  <li>
    <p>Les bulletins sont envoyés [-par courriel-] d'une façon qui
    convient au secrétaire. Le secrétaire détermine pour chaque scrutin si
    les votants peuvent changer leurs bulletins.</p>
  </li>
@@ -371,8 +390,7 @@ ne peuvent pas tous outrepasser les décisions de tous ceux qui sont cités
ensuite.</cite></p>
  autant de fois que nécessaire.</li>

  <li>Les deux semaines suivantes sont la période de scrutin pendant
  laquelle les développeurs peuvent envoyer leurs bulletins. [-Les-]
  [-bulletins de l'élection du responsable sont tenus secrets, même après que-]
  [-l'élection est finie.</li>-]{+</li>+}

  <li>Les choix possibles sur les bulletins sont les candidats qui se sont
  désignés et qui ne se sont pas encore retirés, plus le choix « None Of ... »

Déposant de la proposition B

Judit Foglszinger [[email protected]] [texte de la proposition]

Parrains de la proposition B

  1. Scott Kitterman [[email protected]] [message]
  2. Felix Lechner [[email protected]] [message]
  3. Louis-Philippe Véronneau [[email protected]] [message]
  4. Mathias Behrle [[email protected]] [message]
  5. Tiago Bortoletto Vaz [[email protected]] [message]

Proposition B

Cacher l'identité des développeurs votant à un scrutin particulier et permettre la vérification

Raison

Donner la possibilité de voter pour le secret du vote sans nécessiter de voter en plus pour des modifications de la constitution sans rapport ou avec seulement un rapport éloigné ; par exemple pour la modification du mode de scrutin de vote par courriel à quelque chose d'indéfini.

Comme il a été mentionné durant la discussion, il pourrait ne pas y avoir de consensus sur quelles options sont directement en rapport - Cette option concerne le besoin de permettre une vérification (6) comme directement lié au secret du vote, parce qu'autrement, les votes deviendraient complètement invérifiables.

Résumé des modifications

1) L'identité de l'électeur émettant un vote particulier n'est pas rendue publique.

6) Inscrire dans le code que notre système d'élection doit permettre une vérification du résultat du scrutin et doit permettre aux développeurs de confirmer que leur bulletin est inclus dans la liste des bulletins.

<h3>4.2. Procédure</h3>
@@ -228,9 +246,10 @@ ne peuvent pas tous outrepasser les décisions de tous ceux qui sont cités
ensuite.</cite></p>
    <p>
    Les bulletins sont reçus par le secrétaire du projet. Les bulletins, les
    contrôles et les résultats ne doivent pas être révélés pendant la durée du
    scrutin ; après le scrutin, le secrétaire du projet liste tous les
    contenus des bulletins {+avec suffisamment de détail pour que chacun+}
    {+puisse vérifier le résultat de l'élection à partir de la liste des+}
    {+bulletins. L'identité d'un développeur émettant un vote particulier+}
    {+n'est pas rendu publique, mais les développeurs reçoivent une option+}
    {+pour confirmer que leur bulletin est inclus dans la liste des+}
    {+bulletins.
@@ -371,8 +390,7 @@ ne peuvent pas tous outrepasser les décisions de tous ceux qui sont cités
ensuite.</cite></p>
  autant de fois que nécessaire.</li>

  <li>Les deux semaines suivantes sont la période de scrutin pendant
  laquelle les développeurs peuvent envoyer leurs bulletins. [-Les-]
  [-bulletins de l'élection du responsable sont tenus secrets, même après que-]
  [-l'élection est finie.</li>-]{+</li>+}

Déposant de la proposition C

Holger Levsen [[email protected]] [texte de la proposition]

Parrains de la proposition C

  1. Mattia Rizzolo [[email protected]] [message]
  2. Philip Hands [[email protected]] [message]
  3. Mathias Behrle [[email protected]] [message]
  4. Santiago Ruano Rincón [[email protected]] [message]
  5. Gunnar Wolf [[email protected]] [message]
  6. Sven Bartscher [[email protected]] [message]

Proposition C

Réaffirmer les scrutins publics

Dans la mesure où nous pouvons tenir à la fois des scrutins secrets et sans transparence et des scrutins ouverts et transparents, le projet prend la résolution de conserver notre système de vote tel qu'il est.

Raison

La proposition de résolution générale sur le secret du vote est muette sur les détails de sa mise en œuvre, probablement parce qu'en fait, un vote à la fois secret et transparent est impossible à réaliser parfaitement, aussi cette résolution générale est vouée au même sort que le vote de la résolution générale « rendre publique la liste de diffusiondebian-private » qui a été adoptée puis n'a jamais été mise en œuvre.

Un système de vote qui ne serait transparent que pour certains est non démocratique et mènerait à ce que seulement peu de personnes soient dans le secret, ce qui est à l'opposé des objectifs d'ouverture et de transparence de Debian.

Et puis, en ce début de 2022, ce n'est pas le moment d'apporter des changements aussi précipités, c'est aussi pourquoi je souhaite que soit mentionné sur le bulletin « conserver le statu quo » et pas seulement comme « NOTA » (None of the above), mais comme une véritable option.

Quorum

Avec la liste actuelle des développeurs ayant voté, nous avons : 

 Nombre actuel de développeurs = 1023
 Q (racine carrée(nb de développeurs)) / 2 ) = 15.9921855917195
 K min(5, Q )           = 5
 Quorum  (3 x Q )       = 47.9765567751584

Quorum

Données et statistiques

Pour cette résolution générale, comme d'habitude, des statistiques sur les bulletins et les accusés de réception sont rassemblées périodiquement durant la période du scrutin. De plus, la liste des votants sera enregistrée. La feuille de compte pourra être aussi consultée.

Majorités requises

Les propositions 1 et 2 ont besoin d’une majorité qualifiée à 3 contre 1

Majorité

Résultat

Affichage graphique des résultats

Dans le graphique ci-dessus, les nœuds en rose n'ont pas obtenu la majorité requise, le bleu est le gagnant. L’octogone est utilisé pour les options qui n’ont pas battu l'option par défaut.

Dans le tableau suivant, la correspondance ligne[x] colonne[y] représente le nombre de suffrages où le candidat x est classé devant le candidat y. Une explication plus détaillée de la matrice des gagnants peut vous aider à comprendre ce tableau. Pour comprendre la méthode Condorcet, l'entrée de Wikipédia est assez instructive.

Grille des résultats
 Option
  1 2 3 4
Option 1   72 114 149
Option 2 144   142 185
Option 3 137 107   163
Option 4 94 61 68  

En regardant à la ligne 2, colonne 1, Cacher l'identité des développeurs votant à un scrutin particulier et permettre la vérification
est classé devant Cacher l'identité des développeurs votant à un scrutin particulier sur 144 bulletins

En regardant à la ligne 1, colonne 2, Cacher l'identité des développeurs votant à un scrutin particulier
est classé devant Cacher l'identité des développeurs votant à un scrutin particulier et permettre la vérification sur 72 bulletins.

Couples de défaites

Contenu de l'ensemble de Schwartz

Gagnant

Debian utilise la méthode Condorcet pour les élections. De façon très simpliste, la méthode Condorcet pure pourrait s'expliquer ainsi :
Considérer tous les couples possibles de candidats. Le gagnant selon Condorcet, s'il existe, est le candidat qui bat chacun des autres candidats en duel singulier. Le problème est que dans des élections complexes, il pourrait y avoir des relations circulaires dans lesquels A bat B, B bat C et C bat A. La plupart des variations de la méthode Condorcet utilisent divers moyens pour résoudre ces cas. Veuillez lire la méthode Schulze pour de plus amples informations. La variante de Debian est expliquée dans la constitution, au paragraphe A.6

Secrétaire du projet Debian