Satzungsänderung: reduziere die Länge des DPL-Wahlprozesses

Zeitrahmen

Vorschlag und Änderungsantrag Donnerstag, 31. Juli 2007 Mittwoch, 6. August 2007
Diskussionsperiode: Mittwoch, 7. August 2007 Samstag, 22. September 2007
Abstimmungsperiode Sonntag, 23. September 2007, 00:00:00 UTC Sonntag, 7. Oktober 2007, 00:00:00 UTC

Antragsteller

Anthony Towns [[email protected]] [<[email protected]>]

Unterstützer

  1. Wouter Verhelst [[email protected]]
  2. Nico Golde [[email protected]]
  3. Aurelien Jarno [[email protected]]
  4. Aníbal Monsalve Salazar [[email protected]]
  5. Pierre Habouzit [[email protected]]
  6. Andreas Barth [[email protected]]
  7. Steve McIntyre [[email protected]]
  8. Thijs Kinkhorst [[email protected]]
  9. Neil McGovern neilm [[email protected]]
  10. Ana Guerrero [[email protected]]
  11. Julien Cristau [[email protected]]
  12. Marc Brockschmidt [[email protected]]
  13. Steffen Joeris [[email protected]]
  14. Amaya Rodrigo Sastre [[email protected]]
  15. Joerg Jaspert [[email protected]]
  16. Frederik Schueler [[email protected]]
  17. Luk Claes [[email protected]]
  18. Alexander Schmehl [[email protected]]
  19. Antti-Juhani Kaijanaho [[email protected]]
  20. Konstantinos Margaritis [[email protected]]

Text

Wahl 1. Der eigentliche Text des Beschlusses lautet wie folgt. Bitte beachten Sie, dass dies nicht die unterstützenden oder ablehnenden Argumente oder Begründungen enthält. Diese können in den Archiven der debian-vote-Mailingliste gefunden werden.

Ändere Abschnitt 5.2 der Satzung in Bezug auf die Ernennung des Projektleiters um die Nominierungsperiode auf eine Woche zu reduzieren und die Abstimmungsperiode auf zwei Wochen. Im Wdiff-Format:

5.2. Ernennung

  1. Der Projektleiter wird von den Entwicklern gewählt.
  2. Die Wahl beginnt neun sechs Wochen bevor das Amt der Leitung frei wird, oder (wenn es bereits zu spät ist) sofort.
  3. In den darauf folgenden drei Wochen der ersten Woche kann jeder Entwickler sich selbst als Kandidat für das Amt des Projektleiters nominieren. nominieren, und seine Pläne für seine Amtszeit zusammenfassen.
  4. Danach können für drei Wochen keine weiteren Kandidaten nominiert werden; Kandidaten sollten diese Zeit für die Wahlkampagne (um ihre Person und Positionen bekannt zu machen) und zur Diskussion nutzen. Falls es am Ende der Nominierungsfrist keine Kandidaten gibt, so wird die Nominierung um weitere drei Wochen eine zusätzliche Woche verlängert – falls nötig, wiederholt.
  5. Die nächsten drei zwei sind der Abstimmungszeitraum, in der Entwickler ihre Stimmen abgeben können. Stimmen bei Wahlen für das Amt des Projektleiters werden geheimgehalten, sogar nachdem die Abstimmung beendet ist.
  6. Die Wahlmöglichkeiten auf dem Stimmzettel sind diejenigen Kandidaten, die sich selbst nominiert und die Kandidatur noch nicht zurückgezogen haben, und zusätzlich Niemand von den Obigen. Falls Niemand von den Obigen die Wahl gewinnt, so wird das Wahlverfahren wiederholt – viele Male, falls nötig.
  7. Die Entscheidung wird nach der in §A.6 des Standard-Beschlussverfahrens bestimmten Methode getroffen. Das Quorum ist dasselbe wie für einen Allgemeinen Beschluss (§4.2), und die Vorgabe-Wahlmöglichkeit ist Niemand von den Obigen.
  8. Der Projektleiter amtiert nach seiner Wahl ein Jahr lang.

Antragsteller A der Ergänzung

MJ Ray [[email protected]] [<46b6fd8a.e1VCnIIfHLMNtBlZ%[email protected]>]

Unterstützer A der Ergänzung

  1. Aníbal Monsalve Salazar [[email protected]]
  2. Simon Richter [[email protected]]
  3. Felipe Augusto van de Wiel [[email protected]]
  4. Wesley J. Landaker [[email protected]]
  5. Gaudenz Steinlin [[email protected]]

Text A der Ergänzung

Punkt 5.2 bleibt wie gehabt, d.h. es wird noch wie folgt lauten:

5.2. Ernennung

  1. Der Projektleiter wird von den Entwicklern gewählt.
  2. Die Wahl beginnt neun Wochen, bevor das Amt der Leitung frei wird, oder (wenn es bereits zu spät ist) sofort.
  3. ...

Begründung: Eine Pufferzone von drei Wochen ist nützlich für die Kontinuität und/oder Fälle, in denen die Nominierungsperiode ausgedehnt werden muss. In den letzten Jahren wurde eine Pufferzone bei den DPL-Wahlen hinzugenommen.

Mindestanzahl

Mit der aktuellen Liste von stimmberechtigten Entwicklern haben wir: 


 Aktuelle Entwickler-Anzahl = 1049
 Q ( sqrt(#devel) / 2 ) = 16,1941347407016
 K min(5, Q )           = 5
 Quorum  (3 x Q )       = 48,5824042221049

Quorum

Daten und Statistiken

Für diese GR werden wie immer während der Wahlperiode periodisch Statistiken über die empfangenen Stimmen und die versandten Bestätigungen gesammelt. Zusätzlich würde die Liste der Abstimmenden veröffentlicht. Auch kann die Strichliste angeschaut werden (beachten Sie, dass es sich während des Urnengangs um eine Pseudo-Strichliste handelt).

Mehrheitsanforderung

Da dieser Vorschlag und Änderung die Anpassung eines Gründungsdokuments verlangen würde, genauer gesagt der Satzung, benötigt er eine 3:1-Mehrheit, um angenommen zu werden.

Mehrheit

Ergebnis

Grafische Darstellung der Ergebnisse

In der obigen Graphik implizieren die rosa gefärbte Knoten jene, die nicht die Mehrheit erlangten, der blaue ist der Gewinner. Das Achteck wird für die Optionen verwendet, die nicht den Standard geschlagen haben.

In der folgenden Tabelle repräsentiert tally[Zeile x][Spalte y] die Stimmen, die Option x über Option y erhalten hat. Eine detailliertere Erklärung der Sieg-Matrix kann Ihnen beim Verständnis der Tabelle helfen. Zum Verständnis der Condorcet-Methode ist der Wikipedia-Eintrag recht informativ.

Die Sieg-Matrix
Option
  1 2 3
Option 1   129 196
Option 2 82   159
Option 3 29 51  

Wie in Zeile 2, Spalte 1, Choice 2: As above but do not change election start date in section 5.2.2
82 Stimmen gegenüber Choice 1: Reduce the length of DPL election process

Wie in Zeile 1, Spalte 2 sichtbar, erhielt Choice 1: Reduce the length of DPL election process
129 Stimmen gegenüber Choice 2: As above, but do not change election start date in section 5.2.2.

Paarweise Niederlagen

Die Schwartz-Menge enthält

Die Gewinner

Debian benutzt die Condorcet-Methode für Abstimmungen. Vereinfachend kann die grundlegende Condorcet-Methode folgendermaßen beschrieben werden:
Ziehe alle möglichen Zweikämpfe zwischen den Kandidaten in Betracht. Der Condorcet-Gewinner, falls es einen gibt, ist derjenige Kandidat, der jeden anderen Kandidaten im Zweikampf schlagen kann. Das Problem ist, dass es bei komplexen Wahlen durchaus zu einer kreisförmigen Beziehung kommen kann, in der A über B siegt, B über C siegt und C über A siegt. Die meisten Variationen von Condorcet verwenden verschiedene Mittel, um diese Pattsituation aufzulösen. Siehe Cloneproof Schwartz Sequential Dropping für Details. Die Variation von Debian ist in der Satzung schriftlich festgehalten, speziell § A.6.

Manoj Srivastava