Constitution Debian

Constitution du projet Debian (version 1.4)

Version 1.4 ratifiée le 7 octobre 2007. Remplace la version 1.3 ratifiée le 24 septembre 2006, qui elle-même remplace la version 1.2 ratifiée le 29 octobre 2003, qui elle-même remplace la version 1.1 ratifiée le 21 juin 2003, qui elle-même remplace la version 1.0 ratifiée le 2 décembre 1998.

1. Introduction

Le projet Debian est une association d'individus qui ont pris pour cause commune la création d'un système d'exploitation libre.

Ce document décrit la structure organisationnelle pour les prises de décisions formelles dans le projet. Il ne décrit pas les buts du projet ni comment il les atteint, ni ne contient aucune règle excepté celles directement relatives au processus de prise de décision.

2. Corps et individus prenant les décisions

Chaque décision dans le projet est faite par au moins l'un des suivants :

  1. Les Développeurs, par résolution générale ou par vote.
  2. Le responsable du projet.
  3. Le comité technique et/ou son président.
  4. Le développeur individuel travaillant sur une certaine tâche.
  5. Les délégués nommés par le responsable du projet pour des tâches spécifiques.
  6. Le secrétaire du projet.

La plus grosse partie du reste de ce document esquisse les pouvoirs de ces corps, leur composition et leur nomination, ainsi que les procédures de leurs prises de décisions. Les pouvoirs d'une personne ou d'un corps peuvent être sujet à révision et/ou limitation par d'autres ; dans ce cas le passage concernant le corps ou la personne pouvant faire la révision l'indiquera. Dans la liste ci-dessus, une personne ou un corps est habituellement cité avant les personnes ou les corps dont ils peuvent outrepasser les décisions ou qu'ils nomment (ou aident à nommer) — mais ceux qui sont cités avant ne peuvent pas tous outrepasser les décisions de tous ceux qui sont cités ensuite.

2.1. Règles générales

  1. Rien dans cette constitution n'impose à quiconque d'obligation de faire un travail pour le projet. Une personne qui ne veut pas faire une tâche qui lui a été déléguée ou assignée n'a pas à la faire. Cependant, elle ne doit pas travailler activement contre ces règles et les décisions prises convenablement qui en découlent.

  2. Une personne peut cumuler plusieurs postes, excepté le fait que le responsable du projet, le secrétaire du projet et le président du comité technique doivent être distincts, et que le responsable ne peut pas les nommer pour être ses propres délégués.

  3. Une personne peut quitter le projet ou démissionner d'un poste particulier qu'elle tient, à n'importe quel moment, en le disant publiquement.

3. Les développeurs individuels

3.1. Pouvoirs

Un développeur individuel peut

  1. prendre n'importe quelle décision technique ou non technique en rapport avec son propre travail ;
  2. proposer ou soutenir des projets de résolutions générales ;
  3. se proposer lui-même comme candidat pour les élections au poste de responsable du projet ;
  4. voter les résolutions générales et lors des élections au poste de responsable du projet.

3.2. Composition et nomination

  1. Les développeurs sont des volontaires qui s'accordent à poursuivre les buts du projet en ce qu'ils y participent, et qui maintiennent des paquets pour le projet ou font tout autre travail que les délégués du responsable du projet considèrent utile.

  2. Les délégués du responsable du projet peuvent choisir de ne pas admettre de nouveaux développeurs, ou d'expulser des développeurs existant. Si les développeurs pensent que les délégués abusent de leur autorité, ils peuvent bien sûr outrepasser la décision par résolution générale — voir §4.1(3), §4.2.

3.3. Procédure

Les développeurs peuvent prendre leurs décisions comme ils le souhaitent.

4. Les développeurs par résolution générale ou élection

4.1. Pouvoirs

Ensemble, les Développeurs peuvent :

  1. Nommer ou révoquer le responsable du projet.

  2. Amender cette constitution, pourvu qu'ils soient d'accord avec une majorité qualifiée de 3 contre 1.

  3. Prendre ou outrepasser n'importe quelle décision autorisée par le pouvoir du responsable du projet ou d'un délégué.

  4. Prendre ou outrepasser n'importe quelle décision autorisée par le pouvoir du comité technique, pourvu qu'ils soient d'accord avec une majorité qualifiée de 2 contre 1.

  5. Produire, mettre à jour ou retirer des déclarations ou des documents régulateurs non techniques.

    Ceci inclut des documents décrivant les buts du projet, ses relations avec d'autres entités du logiciel libre, et des règles non techniques comme les termes de la licence de logiciel libre que les logiciels Debian doivent satisfaire.

    Cela peut aussi inclure des déclarations de position concernant les problèmes du jour.

    1. Un document fondateur est un document ou une déclaration considéré comme critique pour la mission ou les objectifs du projet.
    2. Les documents fondateurs sont les travaux appelés Contrat social Debian et Les principes du logiciel libre selon Debian.
    3. Il est nécessaire d'avoir une majorité qualifiée de 3 contre 1 pour mettre à jour un document fondateur. Les nouveaux documents fondateurs sont introduits et les documents fondateurs existants sont retirés, en amendant la liste des documents fondateurs dans cette constitution.
  6. Prendre les décisions à propos des biens administrés pour les besoins de Debian. (Voir §9.)

  7. Désigner un nouveau secrétaire en cas de désaccord entre le responsable du projet et le secrétaire auquel cela incombe.

4.2. Procédure

  1. Les développeurs suivent la procédure standard de résolution ci-dessous. Une résolution ou un amendement est introduit s'il est proposé par n'importe quel développeur et soutenu par au moins K autres développeurs, ou s'il est proposé par le responsable du projet ou le comité technique.

  2. Retarder une décision du responsable du projet ou d'un délégué :

    1. Si le responsable du projet ou ses délégués, ou le comité technique, a pris une décision, alors les développeurs peuvent l'outrepasser en adoptant une résolution pour cela ; voir §4.1(3).
    2. Si une telle résolution est soutenue par au moins 2K développeurs, ou si elle est proposée par le comité technique, la résolution suspend la décision immédiatement (pourvu que la résolution elle-même le demande).
    3. Si la décision originale était de changer la période de discussion ou de vote, ou si la résolution est d'outrepasser le comité technique, alors seulement K développeurs doivent soutenir la résolution pour pouvoir suspendre immédiatement la décision.
    4. Si la décision est suspendue, un vote immédiat se tient pour déterminer si la décision sera applicable jusqu'à ce que le vote complet sur la décision soit fait ou si l'implantation de la décision originale sera retardée jusqu'à ce moment-là. Il n'y a pas de quorum pour ce vote de procédure immédiat.
    5. Si le responsable du projet (ou le délégué) retire la décision originale, le vote devient inutile, et la procédure s'arrête.
  3. 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. La durée du scrutin est de 2 semaines, mais elle peut être modifiée d'au plus une semaine par le responsable du projet.

  4. La période de discussion minimum est de 2 semaines, mais elle peut être modifiée d'au plus une semaine par le responsable du projet. Le responsable du projet a un vote discriminant. Il y a un quorum de 3Q.

  5. Les propositions, soutiens, amendements, appels au vote et autres actions formelles sont faites par annonces sur une liste de discussion électronique à lecture publique désignée par le délégué du responsable du projet ; n'importe quel développeur peut poster sur celle-ci.

  6. Les bulletins sont envoyés par courriel d'une façon qui convienne au secrétaire. Le secrétaire détermine pour chaque scrutin si les votants peuvent changer leurs bulletins.

  7. Q est la moitié de la racine carré du nombre de développeurs courant. K est le minimum de Q et de 5. Q et K ne sont pas forcément entiers et ne sont pas arrondis.

5. Le responsable du projet

5.1. Pouvoirs

Le responsable du projet peut :

  1. Nommer des délégués ou déléguer des décisions au comité technique.

    Le responsable peut définir un domaine de responsabilité ou une décision courante spécifique et la confier à un autre développeur ou au comité technique.

    Une fois qu'une décision particulière a été déléguée et faite, le responsable du projet ne peut retirer cette délégation ; cependant, il peut retirer une délégation courante d'un domaine de responsabilité particulier.

  2. Prêter de l'autorité à d'autres développeurs.

    Le responsable de projet peut faire des déclarations de soutien à des points de vue ou à d'autres membres du projet, que cela lui soit demandé ou non ; ces déclarations ont du poids si et seulement si le responsable a le pouvoir de prendre la décision en question.

  3. Prendre n'importe quelle décision qui demande une action urgente.

    Cela ne s'applique pas aux décisions qui sont seulement devenues graduellement urgente à cause d'un manque d'action significative, sauf s'il y a une date butoir.

  4. Prendre n'importe quelle décision pour laquelle personne d'autre n'a de responsabilité.

  5. Proposer des résolutions générales et des amendements.

  6. Nommer, avec le comité technique, de nouveaux membres au comité. (Voir §6.2.)

  7. Utiliser un vote discriminant quand les développeurs votent.

    Le responsable de projet a aussi un vote normal dans ces scrutins.

  8. Changer la période de discussion des votes des développeurs (comme ci-dessus).

  9. Mener les discussions parmi les développeurs.

    Le responsable de projet devrait essayer de participer aux discussions entre les développeurs d'une manière utile qui cherche à amener la discussion à traiter des problèmes clés en suspend. Le responsable de projet ne devrait pas utiliser sa position d'autorité pour promouvoir ses vues personnelles.

  10. Prendre, en concertation avec les développeurs, les décisions affectant les biens administrés pour les besoins relatif à Debian (Voir §9.). Ces décisions sont communiquées aux membres par le responsable du projet ou ses délégués. Les dépenses importantes devraient être proposées et débattues sur la liste de diffusion avant que les fonds ne soient déboursés.

  11. Ajouter ou supprimer des organisations de la liste des organismes habilités (voir §9.3) qui sont autorisées à accepter et à détenir des capitaux pour Debian. Les évaluations et les discussions conduisant à de telles décisions ont lieu sur une liste de diffusion électronique désignée par le responsable du projet ou ses délégués et sur laquelle tout développeur peut poster. La période de débat minimale est de deux semaines avant qu'un organisme ne puisse être ajouté à la liste des organismes habilités.

5.2. Nomination

  1. Le responsable de projet est élu par les développeurs.
  2. Une élection commence six semaines avant que le poste de responsable ne devienne vacant, ou (si c'est déjà trop tard) immédiatement.
  3. Pendant la première semaine suivante n'importe quel développeur peut se porter candidat au poste de responsable du projet et faire un résumé de ce qu'il souhaite accomplir pendant son mandat.
  4. Pendant les trois semaines suivantes, aucun candidat ne peut plus se présenter ; les candidats devraient utiliser cette période pour faire campagne et débattre. S'il n'y a pas de candidats à la fin de la période de désignation alors cette période est étendue d'une semaine supplémentaire, autant de fois que nécessaire.
  5. 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.
  6. 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 The Above (Aucun de ceux qui précèdent). Si le choix None Of The Above gagne l'élection alors la procédure d'élection est recommencée, plusieurs fois si nécessaire.
  7. La décision est prise en utilisant la méthode spécifiée dans la section §A.6 de la procédure de résolution standard. Le quorum est le même que pour une résolution générale (§4.2) et l'option par défaut est None Of The Above.
  8. Le responsable du projet est désigné pour une année à compter de son élection.

5.3. Procédure

Le responsable du projet devrait essayer de prendre des décisions qui sont cohérentes avec le consensus d'opinions des développeurs.

Lorsque c'est possible le responsable du projet devrait solliciter de manière informelle les opinions des développeurs.

Le responsable du projet devrait éviter de trop souligner son propre point de vue quand il s'agit de prendre des décisions qui relèvent de ses attributions de responsable.

6. Comité technique

6.1. Pouvoirs

Le Comité technique peut :

  1. Décider sur n'importe quel sujet concernant les règles techniques.

    Cela inclut le contenu des manuels de règles techniques, des documents de référence pour les développeurs, des paquets exemples et le comportement des outils non expérimentaux de création de paquets (dans chaque cas, le responsable du logiciel concerné ou de la documentation prend les décisions initialement, cependant ; voir 6.3(5)).

  2. Décider sur n'importe quel sujet technique où les juridictions des développeurs se recouvrent.

    Dans les cas où les développeurs ont besoin d'implanter des règles techniques compatibles ou des décisions (par exemple, s'ils ne sont pas d'accord sur les priorités de paquets en conflit, ou pour attribuer la propriété d'un nom de commande, ou pour déterminer quel paquet est responsable d'un bogue que les deux responsables reconnaissent être un bogue, ou pour désigner le responsable d'un paquet), le comité technique peut décider sur le sujet.

  3. Prendre une décision quand on le lui demande.

    Une personne ou un corps peut déléguer une décision de son ressort au comité technique, ou chercher conseil auprès de lui.

  4. Outrepasser un développeur (demande une majorité qualifiée de 3 contre 1).

    Le comité technique peut demander à un développeur de choisir une solution technique particulière même si le développeur ne le souhaite pas ; cela demande une majorité qualifiée de 3 contre 1. Par exemple, le comité peut décider qu'une doléance faite par une personne soumettant un bogue est justifiée et que la solution proposée par celui qui soumet le bogue devrait être implantée.

  5. Offrir conseil.

    Le comité technique peut faire des annonces formelles à propos de ses vues sur n'importe quel sujet. Les membres individuels peuvent bien sûr faire des déclarations informelles à propos de leurs vues et à propos des vues probables du comité.

  6. Nommer, avec le responsable du projet, de nouveaux membres en son sein ou en retirer (Voir §6.2.).

  7. Nommer le président du comité technique.

    Le président est élu par le comité parmi de ses membres. Tous les membres du comité sont automatiquement candidats ; le comité vote en commençant une semaine avant que le poste ne devienne vacant (ou immédiatement, si c'est déjà trop tard). Les membres peuvent voter par acclamation publique pour n'importe quel membre du comité, y compris eux-mêmes ; il n'y a pas de choix par défaut. Le vote se termine lorsque tous les membres ont voté ou quand la période du scrutin se termine. Le résultat est déterminé en utilisant la méthode décrite dans la section A.6 de la procédure standard de résolution.

  8. Le président peut, avec le secrétaire, représenter le responsable.

    Comme détaillé dans §7.1(2), le président du comité technique et le secrétaire du projet peuvent ensemble représenter le responsable s'il n'y a pas de responsable.

6.2. Composition

  1. Le comité technique est constitué d'au plus 8 développeurs, et devrait normalement avoir au moins 4 membres.

  2. Quand il y a moins de 8 membres le comité technique peut recommander un nouveau membre (ou plus) au responsable du projet, qui peut choisir (individuellement) de les nommer ou pas.

  3. Quand il y a 5 membres ou moins, le comité technique peut nommer de nouveaux membres jusqu'à ce que le nombre de membres atteigne 6.

  4. Quand il y a eu 5 membres ou moins pendant au moins une semaine, le responsable du projet peut nommer de nouveaux membres jusqu'à ce que le nombre de membres atteigne 6, à intervalles d'au moins une semaine par nomination.

  5. Si le comité technique et le responsable du projet sont d'accord, ils peuvent révoquer ou remplacer un membre existant du comité technique.

6.3. Procédure

  1. Le comité technique utilise la procédure standard de résolution.

    Une proposition de résolution ou un amendement peut être proposé par n'importe quel membre du comité technique. Il n'y a pas de période de discussion minimum ; la période de vote dure jusqu'à une semaine, ou jusqu'à ce que le résultat ne fasse plus de doute. Les membres peuvent modifier leurs votes. Il y a un quorum de deux.

  2. Détails concernant le vote.

    Le président a une voix discriminante. Lorsque le comité technique vote pour outrepasser un développeur qui est aussi un membre du comité, ce membre ne peut pas voter (sauf s'il s'agit du président, auquel cas il ne peut utiliser que sa voix discriminante).

  3. Discussion publique et prise de décision.

    Les discussions, propositions de résolutions et amendements, et votes par les membres du comité, sont rendus publics sur la liste de discussion du comité technique. Il n'y a pas de secrétariat séparé pour le comité.

  4. Confidentialité des nominations.

    Le comité technique peut rendre confidentielles les discussions par courriel privé ou par liste de diffusion privée ou d'autres moyens afin de discuter les nominations au comité. Cependant, les votes des nominations doivent être publics.

  5. Pas de travail de conception détaillé.

    Le comité technique ne s'engage pas dans la conception de nouvelles propositions et de nouvelles règles. Ce travail de conception doit être mené par les individus de manière privée ou ensemble et discuté dans des forums techniques ordinaires de conception et de choix de l'implantation.

    Le comité technique se restreint à choisir ou adopter des compromis entre les solutions et décisions qui ont été proposées et suffisamment bien discutées ailleurs.

    Les membres individuels du comité technique peuvent bien sûr participer en leur propre nom à tous les aspects du travail de conception et de choix d'implantation.

  6. Le comité technique prend les décisions uniquement en dernier ressort.

    Le comité technique ne prend pas de décision technique tant que des efforts de résolution par consensus n'ont pas été menés et n'ont pas échoué sauf s'il lui a été demandé de prendre la décision par la personne ou le corps qui en serait normalement responsable.

7. Le secrétaire du projet

7.1. Pouvoirs

Le secrétaire :

  1. Reçoit les votes des développeurs, et détermine le nombre et l'identité des développeurs, quand c'est requis par la constitution.

  2. Peut représenter le responsable, avec le président du comité technique.

    S'il n'y a pas de responsable du projet alors le président du comité technique et le secrétaire du projet peuvent par accord mutuel prendre des décisions s'ils considèrent comme impératif de le faire.

  3. Résout les divergences d'interprétation de la constitution.

  4. Peut déléguer une part ou toute son autorité à quelqu'un d'autre, ou révoquer une telle délégation à tout moment.

7.2. Nomination

Le secrétaire du projet est nommé par le responsable du projet et le secrétaire du projet courant.

Si le responsable du projet et le secrétaire du projet courant ne peuvent se mettre d'accord sur une nouvelle nomination, ils doivent demander aux développeurs de nommer un secrétaire par voie de résolution générale.

S'il n'y a pas de secrétaire du projet ou si le secrétaire courant n'est pas disponible et n'a pas délégué d'autorité pour une décision alors la décision peut être faite ou déléguée par le président du comité technique, en tant que secrétaire intérimaire.

La durée du mandat de secrétaire du projet est d'un an, à la suite duquel lui ou un autre secrétaire doit être (re)nommé.

7.3. Procédure

Le secrétaire du projet devrait prendre des décisions justes et raisonnables, et de préférence en accord avec le consensus des développeurs.

Quand ils agissent ensemble pour représenter un responsable du projet absent, le président du comité technique et le secrétaire du projet devraient prendre des décisions seulement quand c'est absolument nécessaire et seulement en accord avec le consensus des développeurs.

8. Les délégués du responsable du projet

8.1. Pouvoirs

Les délégués du responsable du projet :

  1. ont les pouvoirs qui leurs sont délégués par le responsable du projet ;
  2. peuvent prendre certaines décisions que le responsable ne peut prendre directement, y compris approuver ou expulser des développeurs ou désigner des gens comme développeurs qui ne maintiennent pas de paquets. C'est pour éviter la concentration des pouvoirs, particulièrement au sujet de la qualité de développeur, dans les mains du responsable du projet.

8.2. Nomination

Les délégués sont nommés par le responsable du projet et peuvent être remplacés par le responsable à sa discrétion. Le responsable du projet ne peut rendre le poste de délégué conditionnel à des décisions particulières du délégué, ni outrepasser une décision prise par un délégué une fois prise.

8.3. Procédure

Les délégués peuvent prendre les décisions selon leur convenance, mais devraient essayer d'implanter de bonnes décisions techniques et/ou suivre l'opinion consensuelle.

9. Capitaux administrés pour Debian

Dans la plupart des juridictions au monde, le projet Debian n'est pas en situation de détenir directement des fonds ou d'autres biens. Ainsi, les biens doivent être détenus par un certain nombre d'organismes comme indiqué en §9.2.

Traditionnellement, SPI était l'unique organisme autorisé à détenir des biens et de l'argent pour le projet Debian. SPI a été créée aux États-Unis pour y administrer l'argent.

SPI et Debian sont des organismes séparés qui partagent certains buts. Debian remercie SPI pour le support légal offert par cette organisation.

9.1. Relations avec les organismes associés

  1. Les Développeurs Debian ne deviennent pas des agents ou des employés des organismes qui administrent les capitaux pour Debian, ni les uns des autres, ni de personnes ayant des responsabilités dans le projet Debian, par le simple fait d'être développeur Debian. Une personne agissant en tant que développeur le fait en tant qu'individu, de son propre chef. De tels organismes peuvent, selon leurs propres règles, établir des relations avec des individus qui sont également développeurs Debian.

9.2. Autorité

  1. Un organisme administrant des capitaux pour Debian n'a aucune autorité concernant les décisions techniques ou non techniques de Debian, excepté qu'aucune décision de Debian concernant ses biens détenus par l'organisme ne nécessite qu'il agisse hors de son autorité légale.

  2. Debian ne revendique aucune autorité sur un organisme administrant des capitaux pour Debian autre que l'utilisation des biens administrés pour Debian.

9.3. Organismes habilités

Tout don au projet Debian doit être fait à n'importe quel organisme désigné par le responsable du projet (ou ses délégués) et autorisé à administrer les capitaux utilisables par le projet Debian.

Les organismes administrant des capitaux pour Debian doivent s'engager à des obligations raisonnables dans la gestion de ces capitaux.

Debian gère une liste publique des organismes habilités qui acceptent des dons et administrent des capitaux pour Debian (cela comprend à la fois les biens physiques et la propriété intellectuelle) y compris des engagements que ces organismes ont pris sur la manière de gérer ces capitaux.

A. Procédure de résolution standard

Ces règles s'appliquent aux prises de décision communes par comités et plébiscites, là où cela est indiqué plus haut.

A.1. Proposition

La procédure formelle commence quand un projet de résolution est proposé et soutenu, comme il est requis.

A.1. Discussion et amendements

  1. Après la proposition, la résolution peut être discutée. Les amendements peuvent être rendus formels en étant proposés et soutenus conformément aux exigences d'une nouvelle résolution, ou directement par le déposant de la résolution originale.
  2. Un amendement formel peut être accepté par le déposant de la résolution, dans ce cas la proposition de résolution formelle est immédiatement modifiée pour s'y accorder.
  3. Si un amendement formel n'est pas accepté, ou si l'un des parrains de la résolution n'est pas d'accord avec l'acceptation d'un amendement formel par le déposant de la résolution, l'amendement reste un amendement et sera mis au vote.
  4. Si un amendement accepté par le déposant originel de la résolution n'est pas du goût d'autres développeurs, ils peuvent proposer un autre amendement pour inverser les changements précédents (de même, ils doivent satisfaire aux exigences relatives à son déposant et ses parrains).
  5. Le déposant de la résolution peut suggérer des modifications à la rédaction des amendements ; ils prennent effet si le déposant de l'amendement est d'accord et si aucun de ses parrains ne s'y oppose. Dans ce cas les amendements modifiés seront votés à la place des amendements originaux.
  6. Le déposant d'une résolution peut faire des modifications pour corriger des erreurs mineures (par exemple, des erreurs typographiques ou des incohérences) ou changements qui n'en modifient pas la signification, pourvu que personne ne s'y oppose dans les 24 heures. Dans ce cas, la période de discussion minimum n'est pas recommencée.

A.2. Appel à voter

  1. Le déposant ou l'un des parrains d'une motion ou d'un amendement peuvent appeler à voter, pourvu que la période de discussion minimum (s'il y en a) soit terminée.
  2. Le déposant ou l'un des parrains d'une résolution peuvent appeler à voter sur cette résolution et tous les amendements liés.
  3. La personne qui appelle à voter déclare ce qu'elle croit devoir être la formulation de la résolution et des amendements liés, et en conséquence ce que la forme du bulletin doit être. Cependant, la décision finale sur la forme du ou des bulletins est celle du secrétaire - voir 7.1(1), 7.1(3) et A.3(4).
  4. La période de discussion minimum est comptée à partir du moment où le dernier amendement formel a été accepté, ou à partir du moment où l'entière résolution a été proposée si aucun amendement n'a été proposé et accepté.

A.3. Procédure de vote

  1. Chaque résolution et les amendements qui lui sont liés sont soumis au vote en un seul scrutin qui contient une option pour la résolution originale, pour chaque amendement, et pour l'option par défaut (quand elle s'applique).
  2. L'option par défaut ne doit nécessiter aucune majorité qualifiée. Les options qui ne nécessitent pas de majorité qualifiée ont besoin d'une majorité de 1 contre 1 pour être adoptées.
  3. Les votes sont comptabilisés suivant les règles de A.6. L'option par défaut est Further Discussion (Prolonger la discussion), sauf en cas de spécification contraire.
  4. En cas de doutes le secrétaire du projet devra décider sur les questions de procédure.

A.4. Retrait des résolutions et des amendements non encore acceptés

Le déposant d'une résolution ou d'un amendement non encore accepté peut le retirer. Dans ce cas, certains peuvent vouloir le (ou la) garder, auquel cas la première personne qui souhaite le (ou la) garder devient le nouveau déposant et les autres des parrains si ce n'est pas déjà le cas.

Les parrains d'une résolution ou d'un amendement (sauf s'il a été accepté) peuvent se retirer.

Si le retrait du déposant ou des parrains implique qu'une résolution ou un amendement ne soit plus proposé ou n'ai pas assez de personnes qui le soutienne il ne sera pas voté sauf si cela est rectifié avant que la résolution expire.

A.5. Expiration

Si une résolution proposée n'a pas été discutée, amendée, votée ou traitée d'une façon ou d'une autre pendant 4 semaines, le secrétaire peut décréter que la résolution est retirée. Si aucun parrain d'une des propositions ne manifeste son désaccord pendant une semaine, la résolution est retirée.

Le secrétaire peut, si nécessaire, suggérer des façons de procéder.

A.6. Comptabilisation des votes

  1. Chaque bulletin de vote classe les options soumises au vote. Il n'est pas nécessaire que toutes les options apparaissent dans le classement. Les options apparaissant dans le classement sont considérées comme préférées à toutes celles qui n'y apparaissent pas. Les votants peuvent classer à égalité plusieurs options. Les options non classées sont considérées comme étant à égalité les unes avec les autres. Les détails sur la façon dont les bulletins doivent être remplis seront contenus dans l'appel à voter.
  2. Si le scrutin nécessite un quorum R, toute option autre que celle par défaut, qui ne reçoit pas au moins R votes qui la classent au-dessus de l'option par défaut, est ignorée.
  3. Toute option (autre que celle par défaut), qui ne bat pas l'option par défaut avec un rapport au moins égal à celui de la majorité requise, est ignorée.
    1. Étant données deux options A et B, V(A,B) est le nombre de votants préférant l'option A à l'option B.
    2. Une option A bat l'option par défaut D avec un rapport de majorité N, si V(A,D) est strictement supérieur à N * V(D,A).
    3. Si une majorité qualifiée de S contre 1 est nécessaire pour A, son rapport de majorité est S ; sinon, il est égal à 1.
  4. À partir de la liste des options non ignorées, nous générons une liste des vainqueurs deux à deux.
    1. Une option A bat une option B, si V(A,B) est strictement supérieur à V(B,A).
  5. À partir de la liste des vainqueurs [non-ignorés] deux à deux, nous générons un ensemble des vainqueurs transitifs.
    1. Une option A bat transitivement une option C si A bat C ou s'il existe une autre option B telle que A bat B ET B bat transitivement C.
  6. Nous construisons l'ensemble de Schwartz à partir de l'ensemble des vainqueurs transitif.
    1. Une option A est dans l'ensemble de Schwartz si pour toutes les options B, soit A bat transitivement B, soit B ne bat pas transitivement A.
  7. S'il y a des options qui en battent d'autres dans l'ensemble de Schwartz, nous sortons les plus faibles des vainqueurs de la liste des vainqueurs deux à deux, et retournons à l'étape 5.
    1. Une victoire (A,X) est plus faible qu'une victoire (B,Y) si V(A,X) est inférieur à V(B,Y). Et de plus, (A,X) est plus faible que (B,Y) si V(A,X) est égal à V(B,Y) et V(X,A) est plus grand que V(Y,B).
    2. Une plus faible victoire est une victoire qui n'a pas de victoire plus faible qu'elle. Il peut y avoir plusieurs victoires de ce type.
  8. S'il n'y a pas de plus faible dans l'ensemble de Schwartz, alors le vainqueur est choisi dans l'ensemble de Schwartz. S'il n'y a qu'une seule option, c'est le vainqueur. S'il y en a plusieurs, le votant ayant un vote discriminant choisit l'option qui gagne parmi celles-ci.

Note : Les options que les votants classent au-dessus de l'option par défaut sont celles qu'ils trouvent acceptables. Les options classées au-dessous de l'option par défaut sont les options qu'ils trouvent inacceptables.

Quand la procédure de résolution standard est utilisée, le texte qui y fait référence doit spécifier ce qui est suffisant pour qu'une proposition de résolution soit proposée et/ou soutenue, ce qu'est la période de discussion minimum, et ce qu'est la période de vote. Il doit aussi spécifier quelle majorité qualifiée et/ou le quorum (et le choix par défaut) à utiliser.

B. Utilisation du langage et typographie

Le présent ou le futur de l'indicatif (est ou sera, par exemple) signifie que l'affirmation est une règle dans cette constitution. Le verbe pouvoir indique que la personne ou le corps a le choix. Le verbe devoir au conditionnel indique que cela serait considéré comme une bonne chose si ce qui prescrit était respecté, mais cela n'est pas obligatoire. Le texte marqué comme une citation, comme celui ci, se veut simplement raisonnable et ne fait pas partie de la constitution. Il peut être utilisé seulement pour aider à l'interprétation en cas de doute.