Do-ocratie, ou docratie (forme mixte, à partir de l'anglais. do-, faire, et du grec ancien -cratie, gouverner ; la forme correcte serait poïéocratie, du grec ancien poïéo-, faire, et -cratie, gouverner) est une forme d'organisation dans laquelle les individus ont du pouvoir à la mesure de ce qu'ils accomplissent, des tâches qu'ils choisissent et exécutent de manière autonome. Les responsabilités sont confiées aux individus et pas aux postes qu'ils occupent.
« En do-ocratie, chacun a de l’influence ou du pouvoir à la mesure de ce qu’il fait. C’est un modèle particulièrement efficace pour faciliter la prise d’initiative et l’implication par le plus grand nombre. La do-ocratie est au cœur du fonctionnement des wikis et des hackerspaces. »
À l'origine, ce modèle serait issu du Parti libertarien américain de Sean Haugh et Michael Gilson-De Lemos. Il est aujourd'hui avant tout utilisé au sein des communautés de l'open source et des fablabs. Il est aussi populaire parmi les participants du festival Burning Man (États-Unis).
Il s'agit d'un principe mis en avant par le Hackerspace de Gand :
How?
A do-ocracy naturally emerges when the environment is right. There are a number of important factors.
• Allow people to fail. People need to feel safe knowing that they are allowed to try, and to fail. Thus, when people fail, we need to be kind and help them get better instead of berating them. The hackerspace gives everyone room to grow, and failure is part of that. For more information, read up on the idea of “blameless post-mortems” in the IT operations and DevOps communities.
• Ask for help and help others.
• Trust each other.
• Focus on what you have in common instead of what you disagree on.
• Recognize and reward the people doing stuf.
…
Limitations
Some things are too sensitive to be handled by do-ocracy alone, or are irreversible, like throwing things away. Refer to the Sections on the board, meetings and the guidelines for more information of when strict do-ocracy doesn’t apply.
In general, if an action is irreversible, do-ocracy does not apply and you should discuss it with the larger group.
Empowering people to be awesome.
La “Constitution Debian” est le document décrivant la structure organisationnelle pour les prises de décision formelles dans le projet.
La version 1.0 date de 1998 et a évolué jusqu'en 2016 avec la dernière version en date : la 1.7
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.
Indique que le projet
Debian est un projet collectif.
2. Corps et individus prenant les décisions
Chaque décision dans le Projet est faite par un ou plus des suivants :
les Développeurs, par Résolution Générale ou par vote ;
le Chef du Projet ;
le Comité Technique et/ou son Président ;
Le Développeur individuel travaillant sur une certaine tâche ;
Des Délégués nommés par le Chef du Projet pour des tâches spécifiques ;
Le Secrétaire du Projet.
La plus grosse partie du reste de ce document esquissera les pouvoirs de ces corps, leur composition et leur nomination, et 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
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.
Une personne peut cumuler plusieurs postes, excepté le fait que le Chef du Projet, le Secrétaire du Projet et le Président du Comité Technique doivent être distincts, et que le Chef ne peut pas les nommer pour être leurs propres Délégués.
Une personne peut quitter le Projet ou démissionner d'un poste particulier qu'elle tient, à n'importe quel moment, en le disant publiquement.
Ensemble des groupes de personnes intervenant dans le projet et rappel des règles générales (cumul de poste, liberté de faire ou ne pas faire…)
3. Les Développeurs Individuels
3.1. Pouvoirs
Un Développeur individuel peut
prendre n'importe quelle décision technique ou non technique en rapport avec son propre travail ;
proposer ou soutenir des projets de Résolutions Générales ;
se proposer lui même comme candidat pour les élections au poste de Chef du Projet ;
voter les Résolutions Générales et lors des élections au poste de Chef du Projet.
3.2. Composition et nomination
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 Chef du Projet considèrent utile.
Les Délégués du Chef 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 ces décisions comme ils le souhaitent.
Le développeur individuel est la personne participant au projet en cherchant à poursuivre les buts de celui-ci.
S'il y a participation et que cette personne n'a pas été expulsée, elle aura le droit de vote, la possibilité de rejoindre des projets ou se présenter en tant que
DPL. Il a également toutes les libertés sur ce qu'il apporté.
4. Les Développeurs par Résolution Générale ou élection
4.1. Pouvoirs
Ensemble, les Développeurs peuvent :
Nommer ou rétrograder le Chef du Projet.
Amender cette constitution, pourvu qu'ils soient d'accord avec une majorité de 3 contre 1.
Outrepasser n'importe quelle décision du Chef du Projet ou d'un Délégué.
Outrepasser n'importe quelle décision du Comité Technique, pourvu qu'ils soient d'accord avec une majorité de 2 contre 1.
Produire des déclarations ou des documents régulateurs non techniques. Ceci inclut des documents décrivant les buts du projet, ces 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.
Ensemble avec le Chef du Projet et SPI, prendre des décisions à propos des biens mis en commun pour les besoins de
Debian (voir §9.1.).
4.2. Procédure
Les Développeurs suivent la Procédure Standard de Résolution, ci dessous. Une résolution ou un amendement est introduit si il est proposé par n'importe quel Développeur et soutenu par au moins K autres Développeurs, ou si il est proposé par le Chef du Projet ou le Comité Technique.
Retarder une décision du Chef du Projet ou d'un Délégué :
Si le Chef du Projet ou son Délégué, 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).
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).
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.
Si la décision est suspendue, un vote immédiat est tenu pour déterminer si la décision sera applicable jusqu'à ce que le vote complet sur la décision soit fait ou si l'implémentation de la décision originale sera retardée jusqu'à ce moment. Il n'y a pas de quorum pour ce vote procédural immédiat.
Si le Chef du Projet (ou le Délégué) retire la décision originale, le vote devient inutile, et n'est plus poursuivi.
Les votes sont reçus par le Secrétaire du Projet. Les votes et les résultats ne doivent pas être révélés pendant la durée de vote ; après le vote, le Secrétaire du Projet liste tous les résultats des votes. La durée de vote est de 2 semaines, mais elle peut être modifiée d'au plus une semaine par le Chef du Projet, et peut être terminée par le Secrétaire du Projet quand le résultat du vote ne fait plus aucun doute.
La période de discussion minimum est de 2 semaines, mais elle peut être modifiée d'au plus une semaine par le Chef du Projet. Le Chef du Projet a un vote discriminant. Il y a un quorum de 3Q.
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 Chef du Projet; n'importe quel Développeur peut poster sur celle-ci.
Les votes sont envoyés par courrier électronique d'une façon qui convienne au Secrétaire. Le Secrétaire détermine pour chaque scrutin si les votants peuvent changer leurs votes.
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.
Les développeurs par résolution générale ou élection sont un ensemble de développeurs individuels qui, une fois le nombre minimum requis, peuvent remettre toute décision prise en question, ou en prendre, au moyen d'un vote, jusqu'à pouvoir outrepasser le pouvoir du
DPL.
Autant il est demandé une fois par an à ceux-ci d'élire le
DPL, autant, à tout moment, ceux-ci peuvent, par exemple, se réunir pour destituer un
DPL.
La procédure fait appel à une formule mathématique, ce qui n'est pas toujours évident à inclure dans un R.O.I. mais elle est assez simple.
Nous allons partir d'un exemple avec 144 membres :
$N = Participants = 144$
$Q = \frac{\sqrt{N}}{2} = 6$
$K = \min(Q,5) = 5$
Il faut 1+K personnes réunies pour que leur demande soit prise en compte, soit 6 personnes.
Si elle est soutenue par 2K, soit 12 personnes, la prise de décision est suspendue pour amener à un vote dont le quorum est de 3Q, soit 18 participants.
Si nous partons de 400 membres :
$N = Participants = 400$
$Q = \frac{\sqrt{N}}{2} = 10$
$K = \min(Q,5) = 5$
Il faut toujours que 6 personnes pour que la demande soit prise en compte et 18 pour suspendre une décision en cours, mais le quorum passe à 30 participants.
Et si nous partons de 12 membres :
$N = Participants = 12$
$Q = \frac{\sqrt{N}}{2} = 1.732$
$K = \min(Q,5) = 1.732$
Il faut ici 2.732 personnes (soit 3) pour que la demande soit prise en compte et 3.46 (soit 3) de plus, donc six en tout, pour que soit soumise à un vote la demande.
Le quorum serait alors de 5.196 personnes, soit 5.
5. Le Chef du Projet
5.1. Pouvoirs
Le Chef du Projet peut :
Nommer des Délégués ou déléguer des décisions au Comité Technique.Le Chef 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 Chef du Projet ne peut retirer cette délégation ; cependant, il peut retirer une délégation courante d'une aire de responsabilité particulière.
Prêter de l'autorité à d'autres Développeurs.Le Chef 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 Chef a le pouvoir de prendre la décision en question.
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.
Prendre n'importe quelle décision pour laquelle personne d'autre n'a de responsabilité.
Proposer des Résolutions Générales et des amendements.
Ensemble avec le Comité Technique, nommer de nouveaux membres au Comité. (Voir §6.2.)
Utiliser un vote discriminant quand les Développeurs votent.Le Chef de Projet a aussi un vote normal dans ces scrutins.
Changer la période de discussion des vote des Développeurs (comme ci-dessus).
Mener les discussions parmi les Développeurs.Le Chef de Projet devrait essayer de participer aux discussions parmi les Développeurs d'une manière utile qui cherche à amener la discussion à traiter des problèmes clés en suspend. Le Chef de Projet ne devrait pas utiliser sa position d'autorité pour promouvoir ses vues personnelles.
Ensemble avec SPI, prendre les décisions affectant les biens possédés en commun pour les besoins relatifs à
Debian. (Voir §9.1.)
5.2. Nomination
Le Chef de Projet est élu par les Développeurs.
Une élection commence neuf semaines avant que le poste de chef ne devienne vacant, ou (si c'est déjà trop tard) immédiatement.
Pendant les trois semaines suivantes n'importe quel Développeur peut se porter candidat au poste de Chef du Projet.
Pendant les trois semaines suivantes, aucun candidat ne peut plus se présenter ; les candidats doivent utiliser cette période pour faire campagne (pour faire connaître leurs identités et leurs positions). S'il n'y a pas de candidat à la fin de la période de désignation alors cette période est étendue de trois semaines supplémentaires, répétitivement si nécessaire.
Les trois semaines suivantes sont la période de scrutin pendant laquelle les Développeurs peuvent envoyer leurs votes. Les votes de l'élection du chef sont tenus secrets, même après que l'élection est finie.
Les choix possibles sur les bulletins seront 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.
La décision sera prise en utilisant le Comptage de Votes Concordants. 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.
Le Chef du Projet est désigné pour une année à compter de son élection.
5.3. Procédure
Le Chef du Projet devrait essayer de prendre des décisions qui sont consistantes avec le consensus d'opinions des Développeurs.
Lorsque c'est possible le Chef du Projet devrait solliciter de manière informelle les opinions des Développeurs.
Le Chef 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 Chef.
Le “Chef de projet” ou DPL, est une personne ayant prouvé sa valeur au sein du projet et choisie démocratiquement par tous les membres que pour les représenter.
6. Comité Technique
6.1. Pouvoirs
Le Comité Technique peut :
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).).
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'implémenter 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.
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.
Outrepasser un Développeur (demande une majorité 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é de 3 contre 1. Par exemple, le Comité peut décider qu'une complainte faite par une personne soumettant un bogue est justifiée et que la solution proposée par celui qui soumet le bogue devrait être implémentée.
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é.
Ensemble avec le Chef du Projet, nommer de nouveaux membres en son sein ou en retirer. (Voir §6.2.)
Nommer le Président du Comité Technique.Le Président est élu par le Comité à partir de ses membres. Tous les membres du Comité sont automatiquement nommés ; le Comité vote en commençant une semaine avant que le poste ne devienne vacant (ou immédiatement, s'il est déjà trop tard). Les membres peuvent voter par acclamation publique pour n'importe quel membre du Comité, y compris eux-même; il n'y a pas de choix None Of The Above. Le vote se termine lorsque tous les membres ont voté ou quand le résultat ne fait plus de doute. Le résultat est déterminé selon le Comptage de Votes Concordants.
Le Président peut représenter le Chef, ensemble avec le Secrétaire.Comme détaillé dans §7.1(2), le Président du Comité Technique et le Secrétaire du Projet peuvent ensemble représenter le Chef s'il n'y a pas de Chef.
6.2. Composition
Le Comité Technique est constitué d'au plus 8 Développeurs, et devrait normalement avoir au moins 4 membres.
Quand il y a moins de 8 membres le Comité Technique peut recommander un nouveau membre (ou plus) au Chef du Projet, qui peut choisir (individuellement) de les nommer ou pas.
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.
Quand il y a eu 5 membres ou moins pendant au moins une semaine, le Chef du Projet peut nommer de nouveaux membres jusqu'à ce que le nombre de membres atteigne 6, à intervalles d'au moins une semaine par nomination.
Si le Comité Technique et le Chef du Projet sont d'accord ils peuvent retirer ou remplacer un membre existant du Comité Technique.
6.3. Procédure
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.
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 peut utiliser seulement sa voix discriminante).
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é.
Confidentialité des nominations.Le Comité Technique peut rendre confidentielles les discussions par courrier électronique 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.
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 d'implémentation.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'implémentation.
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.
Le comité technique est un ensemble de développeurs choisis pour résoudre des conflits naissant de sous-projets entre développeurs individuels et prendre certains types de décisions s'il faut trancher.
Le comité technique élit un Directeur de comité qui, en compagnie du secrétaire du projet, peut représenter le DPL.
7. Le Secrétaire du Projet
7.1. Pouvoirs
Le Secrétaire :
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.
Peut représenter le Chef, avec le Président du Comité Technique.S'il n'y a pas de Chef 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.
Résout les divergences d'interprétation de la constitution.
Peut déléguer une part ou toute son autorité à quelqu'un d'autre, ou retirer une telle délégation à tout moment.
7.2. Nomination
Le Secrétaire du Projet est nommé par le Chef du Projet et le Secrétaire du Projet courant.
Si le Chef du Projet et le Secrétaire du Projet courant ne peuvent se mettre d'accord sur une nouvelle nomination, ils doivent demander au conseil d'administration de SPI de nommer un Secrétaire.
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 en Acte.
La durée du mandat de Secrétaire du Projet est de 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 Chef 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.
Le secrétaire de projet est nommé par le
DPL et est en charge de représenter le
DPL et de recevoir les votes à toutes les différentes prises de décision.
8. Les Délégués du Chef du Projet
8.1. Pouvoirs
Les Délégués du Chef du Projet :
ont les pouvoirs qui leurs sont délégués par le Chef du Projet ;
peuvent prendre certaines décisions que le Chef 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 Chef du Projet.
8.2. Nomination
Les Délégués sont nommés par le Chef du Projet et peuvent être remplacés par le Chef à sa discrétion. Le Chef 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'implémenter de bonnes décisions techniques et/ou suivre l'opinion consensuelle.
Les délégués du chef de projet sont des personnes choisies par le DPL ayant des pouvoirs pouvant être similaire à celui-ci sur des domaines bien précis.
9. Software in the Public Interest
SPI et Debian sont des organisations séparées qui partagent certains buts. Debian remercie SPI pour le support légal offert par cette organisation.Les Développeurs Debian sont des membres courants de SPI de par leur status de Développeurs.
9.1. Autorité
SPI n'a pas d'autorité concernant les décisions techniques ou non techniques de
Debian, excepté que toute décision de
Debian concernant tous les biens gardés par SPI nécessite que SPI agisse en dehors de son autorité légale, et que la constitution de
Debian peut occasionnellement utiliser SPI comme un corps de décision en dernier ressort.
Debian ne revendique aucune autorité sur SPI autre que l'utilisation de certains biens de SPI, comme décrit ci dessous, bien que les Développeurs
Debian peuvent recevoir des responsabilité à l'intérieur de SPI suivant les règles de SPI.
Les Développeurs
Debian ne sont pas des agents ou des employés ni de SPI, ni les uns des autres, ni de personnes ayant des responsabilités dans le Projet
Debian. Une personne agissant en tant que Développeur le fait en tant qu'individu, de son propre chef.
9.2. Gestion des biens pour les besoins de Debian
Comme Debian n'a pas d'autorité légale pour garder de l'argent ou des biens, tous les dons pour le Projet Debian doivent être faits à SPI, qui gère ce type d'affaires.
SPI a pris les engagements suivants :
SPI gardera l'argent, les marques commerciales et les autres biens tangibles et intangibles et gérera des affaires pour les besoins de
Debian ;
Ces biens seront comptabilisés séparément et gardés en commun pour ces besoins, les décisions les concernant seront prises par
Debian et SPI conformément à cette section ;
SPI n'utilisera pas et ne disposera pas de ces biens gardés en commun pour
Debian sans l'approbation de
Debian, qui peut être fournie par le Chef du Projet ou par Résolution Générale des Développeurs ;
SPI pourra utiliser et disposer de ces biens gardés en commun pour
Debian quand cela lui sera demandé par le Chef du Projet ;
SPI utilisera et disposera de ces biens gardés en commun pour
Debian quand cela lui sera demandé par Résolution Générale des Développeurs, pourvu que cela soit compatible avec l'autorité légale de SPI ;
SPI informera les Développeurs par courrier électronique sur la liste de diffusion du Projet
Debian quand il utilisera ou disposera des biens gardés en commun pour
Debian ;
Software in the Public Interest, Inc. (SPI, que l'on peut traduire par « Logiciel dans l'intérêt public ») est une association à but non lucratif constituée dans le but d'aider d'autres organismes à créer et distribuer des logiciels open source ou libres, ainsi que du matériel libre. Toute personne peut en devenir membre. Un membership contributif est offert aux personnes qui participent activement à la communauté du logiciel libre. SPI a été originellement créée pour permettre au projet Debian de recevoir des dons, elle détient notamment la marque Debian. Il lui arrive également de servir d'intermédiaire technique neutre lors de processus démocratiques, par exemple, l'organisation de référendums pour la fondation Wikimedia.
SPI est une association ayant les mêmes “buts” que Debian mais offrant une structure pouvant gérer de l'argent et des biens, ce qui n'est pas le cas du projet Debian en lui-même.
Elle s'est engagée auprès du projet debian et de ses développeurs d'agir en totale transparence quant à l'argent et aux biens employés pour le projet tout en ne pouvant prendre aucune initiative sans l'accord du du chef de projet ou par une résolution générale.
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
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 celui qui a proposé la résolution originale.
Un amendement formel peut être accepté par celui qui propose la résolution, dans ce cas la proposition de résolution formelle est immédiatement modifiée pour s'y accorder.
Si un amendement formel n'est pas accepté, ou si l'un de ceux qui soutiennent la résolution n'est pas d'accord avec l'acceptation d'un amendement formel par celui qui propose la résolution, l'amendement reste un amendement et sera mis au vote.
Si un amendement accepté par celui qui a originellement proposé 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 à celui qui le propose et ceux qui le soutiennent).
Celui qui propose la résolution peut suggérer des modifications à la rédaction des amendements ; ils prennent effet si celui qui propose un amendement est d'accord et si aucun de ceux qui le soutiennent ne s'y oppose. Dans ce cas les amendements modifiés seront votés à la place des amendements originaux.
Celui qui propose 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
Celui qui propose ou l'un de ceux qui soutiennent une motion ou un amendement peuvent appeler à voter, pourvu que la période de discussion minimum (s'il y en a) soit terminée.
Celui qui propose ou l'un de ceux qui soutiennent une motion peuvent appeler à voter sur n'importe lequel ou sur tous les amendements séparément ou ensemble ; celui qui propose ou l'un de ceux qui soutiennent un amendement peuvent appeler à voter seulement sur cet amendement et les amendements liés.
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(6).
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ù le dernier amendement formel lié a été accepté si un amendement est en train d'être voté, ou à partir du moment où l'entière résolution a été proposée si aucun amendement n'a été proposée et acceptée.
A.3. Procédure de vote
Chaque ensemble indépendant d'amendements liés est voté lors d'un scrutin séparé. Chacun de ces scrutin propose autant de choix possible que toutes les combinaisons d'amendements et d'options, ainsi qu'un choix Further Discussion (Discussion Prolongée). Si Further Discussion gagne alors l'entière procédure de résolution est à recommencer en partant de la période de discussion. Aucun quorum n'est requis pour un amendement.
Quand la forme finale de la résolution a été déterminée elle est votée lors d'un dernier scrutin, lors duquel les choix possibles sont Yes (Oui), No (Non) et Further Discussion (Discussion Prolongée). Si Further Discussion gagne alors l'entière procédure est à recommencer en partant de la période de discussion.
La personne qui recueille les votes (s'il y en a une) ou les votants (si le vote est public) peuvent s'arranger pour que ces scrutins soient fait simultanément, même (par exemple) en un seul message de vote. Si les scrutins d'amendement et le scrutin final se déroulent de cette façon alors il doit être possible pour un votant de voter différemment lors du scrutin final pour chacune des formes possibles de la proposition de résolution finale.
Les votes peuvent être envoyés pendant la période de vote, comme spécifié ailleurs. Si la période de vote peut se terminer si le résultat ne fait plus aucun doute, la possibilité que les votants puisse modifier leur vote n'est pas acceptable.
Les votes sont comptés suivant le Comptage des Votes Concordants. Si un quorum est requis alors l'option par défaut est Further Discussion (Discussion Prolongée).
En cas de doutes le Secrétaire du Projet devra décider sur les questions de procédure (par exemple, si un amendement particulier doit être considéré indépendant ou pas).
A.4. Retrait des résolutions et des amendements non encore acceptés
Celui qui propose une résolution ou 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 celui qui le (ou la) propose et les autres soutiennent alors si ce n'est pas déjà le cas.
Ceux qui soutiennent une résolution ou un amendement (sauf s'il a été accepté) peuvent se retirer.
Si le retrait de celui qui propose et/ou de ceux qui soutiennent implique qu'une résolution ou un amendement ne soit plus proposée ou n'ai pas assez de personne qui la soutienne elle ne sera pas voté sauf si cela est rectifié avant que la résolution expire.
A.5. Expiration
Si la résolution proposée n'a pas été discutée, amendée, votée ou en tout cas traitée pendant 4 semaines alors elle est considérée comme ayant été retirée.
A.6. Comptage de Votes Concordants
Cette méthode est utilisée pour déterminer le vainqueur parmi une liste de choix. Chaque bulletin de vote donne l'ordre des choix préférés par le votant (l'ordre ne doit pas nécessairement être complet).
Un choix A est dit Dominer un choix B si strictement plus de bulletin préfèrent A à B qu'il n'y en a qui préfèrent B à A.
Tous les choix qui sont Dominés par au moins un autre choix sont rejetés, et les références à ces choix dans les bulletins seront ignorés.
S'il y a un choix qui Domine tous les autres c'est le gagnant.
S'il y a ensuite plus d'un choix restant, le Vote Unique Transférable sera appliqué pour choisir parmi les choix restant :
Le nombre de première préférence est comptabilisé pour chaque choix, et si un choix en obtient plus de la moitié c'est le gagnant ;
Sinon le choix ayant le plus faible nombre de première préférence est éliminé et ses votes sont redistribués selon la seconde préférence ;
Cette procédure d'élimination est répétée, les choix des bulletins descendent à la 2e, 3e, 4e, etc. préférence comme requis, jusqu'à ce qu'un choix obtienne plus de la moitié des premières préférences.
Dans le cas d'égalité le votant ayant un vote discriminant décidera. Le vote discriminant ne compte pas comme un vote normal ; cependant ce votant aura la plupart du temps un vote normal.
Si une supermajorité est requise le nombre de vote Yes (Oui) dans le scrutin final est réduit d'un facteur approprié. Pour parler clairement, pour une supermajorité de F contre A, le nombre de bulletins qui préfèrent Yes (Oui) à X (quand on considère si Yes Domine X ou X Domine Yes) ou le nombre de bulletins dont la première préférence (restante) est Yes (quand on fait des comparaisons VUT pour le vainqueur et pour les éliminations) est multiplié par un facteur A/F avant que la comparaison soit faite. Cela signifie qu'un vote à 2 contre 1, par exemple, signifie que deux fois plus de gens doivent voter pour que contre ; les abstentions ne sont pas comptés.
Si un quorum est requis, il doit y avoir au moins autant de votes qui préfèrent le choix gagnant que le choix par défaut. S'il n'y en a pas autant, le choix par défaut gagne à la fin. Concernant les votes qui nécessitent une supermajorité, le nombre de votes Yes (Oui) est utilisé pour vérifier que le quorum a été atteint.
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 supermajorité et/ou le quorum (et le choix par défaut) à utiliser.
Déroulement d'un vote.
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.
Indication de ce que sous-entend l'emploi de certains temps dans les déclarations officielles du projet Debian.
Je pense que ce modèle est intéressant. Il faut voir ce qui suit comme une version 0.1 à discuter profondément en GT Gouvernance et qui n'est qu'une extra-polation de ma part du modèle.
Pour l'exemple, je vais à nouveau repartir de notre collectif.
Afin de faire perdurer le nom 11H22, l'association devrait changer de nom. Pour la suite, ce sera ETNIK'Art.
L'objet moral de l'association changerait pour proposer la gestion des biens et avoirs de projets pratiquant un certain type de gouvernance. (subventions ? )
Nous y reviendrons plus tard.
11H22 ne serait alors plus une association mais un projet de l'association. (tout comme Debian est un projet, une “organisation de personnes”, sans aucune personne morale derrière, soutenu par SPI).
Il pourrait alors être documenté comme un projet à part entière Libre et open-source dont la paternité ne pourrait être enlevée à la personne l'ayant initié tout comme chaque modification est reliée à son auteur.
L'association n'aurait pour autre seul but que de soutenir des projets.
Les statuts et un ROI assureraient que la gestion soit totalement transparente et que tout avoir ou somme dédié à un projet ne pourrait être utilisé ailleurs.
Ils assureraient également que toute dépense ne puisse être effectuée sans provenir du PL avec l'aval du collectif.
C'est l'association à qui serait facturé les prestations pour chaque projet.
Et c'est à elle que seraient fait les dons et par qui passeraient les demandes de subsides pour soutenir tel ou tel projet.
C'est elle qui prendra les assurances si nécessaires, etc.
L'association n'est pas là pour prendre des décisions au cas par cas mais se basera sur des chiffres indiquant la viabilité d'un projet en fonction des frais qu'elle engendre et de ce que le projet ramène.
Il ne devra pas être possible d'influer sur les résultats de par des biais cognitifs et affectifs.
Les membres du C.A. seraient Aurélie en tant que présidente, des membres choisis, des membres d'honneurs composés des initiateurs de projets pérènes.
Si un membre du C.A. est PL d'un projet, il ne pourra prendre position et il sera considéré que sa position sera celle de la majorité.