Table des matières

Debian Project Leader

Debian

Il s'agit d'une distribution Linux créée par Ian Murdock en 1993.

En 1996, il passe la main de la gouvernance en établissant le DPL, basé sur le principe de la do-ocratie.

Do-ocratrie

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.


DPL

Définition

Le Chef du Projet Debian (DPL Debian Project Leader) est le représentant officiel du projet Debian. Il a deux principales fonctions, une interne et une externe.

Dans sa fonction externe, le Chef du projet représente le projet Debian aux yeux de l'extérieur. Cela consiste à donner des interviews et à faire des présentations concernant Debian, à participer aux salons, ainsi qu'à construire de bonnes relations avec les autres organisations et entreprises.

En interne, le Chef du projet dirige le projet et définit sa stratégie. Il doit discuter avec les autres développeurs Debian, en particulier les délégués, afin de voir comment il peut les aider dans leur travail. Une des tâches principales du Chef du projet consiste donc à faire de la coordination et de la communication.

Nomination

Le Chef du projet est choisi par une élection à laquelle tous les développeurs Debian sont appelés à voter. La durée du mandat du Chef du projet est d'un an.

Six semaines avant que le poste de Chef du projet ne devienne vacant, le Secrétaire du projet commence la préparation d'une nouvelle élection.

Durant la première semaine, n'importe quel développeur Debian peut devenir candidat à ce poste en se déclarant lui-même.

La campagne électorale se déroule durant les trois semaines qui suivent.

Chaque candidat poste sa plate-forme et n'importe qui peut poser des questions à un ou tous les candidats. Les deux dernières semaines sont la période de vote pendant laquelle les développeurs peuvent voter.

Il est arrivé plusieurs fois qu'une personne soit réélue. Il ne semble pas y avoir de limite imposée au nombre de mandats et le maximum de mandats d'affilé est de 3.

Rôles du DPL

• Nommer les délégués ou déléguer des décisions au Comité Technique

• Prêter son autorité à d'autres développeurs

• Prendre toute décision qui nécessite une action urgente

• Prendre toute décision dont personne d'autre n'est responsable

• Après consultation des développeurs, prendre des décisions affectant les biens possédés en commun dans un but lié à Debian

(Source)


Debian Constitution

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

Indique que le projet Debian est un projet collectif.

2. Corps et individus prenant les décisions

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

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

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

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

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

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

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

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

Déroulement d'un vote.


B. Utilisation du langage et typographie

Indication de ce que sous-entend l'emploi de certains temps dans les déclarations officielles du projet Debian.


Application à un collectif

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.

Le collectif

Ensemble des personnes participant au projet en suivant les buts fixés par le projet. Il suffirait qu'une personne passe la porte, s'entende bien avec nous, comme Manon, et participe en “faisant”, et il n'y aurait pas besoin de passer par des votes dont l'issue est souvent connue d'avance.

Project Leader

Nous l'appellerons par la suite OVDPL (Onze Vingt Deux PL)

Au bout d'un an, le collectif participe à un vote afin d'élire le nouveau OVDPL ou maintenir l'actuel en place. Il n'y a pas de limite au nombre de mandats.

Tout membre du collectif peut se proposer.

Ses devoirs seraient :

Il va de soit qu'il lui est alors possible de tout déléguer pour ne plus rien faire, mais à tout moment un vote peut être demandé également pour la destitution d'un OVDPL ou pour l'exclusion d'une personne au projet.

Mais si un OVDPL n'est pas la personne la plus à même pour représenter le projet publiquement (radio, presse, interview…) il peut parfaitement déléguer ce rôle à la personne de confiance qu'il choisira.

Délégués

Le OVDPL délègue certains de ses droits à qui est leader d'un GT.

Certaines personnes sont leader de plusieurs GT et ont le droit d'avoir plusieurs voix.

Leur seul devoir est d'agir en bon père de famille tout en respectant la philosophie du projet, de ce à quoi ils ont décidé de s'attaquer ou de participer tout en se rendant bien compte qu'absolument toute décision peut être remise en question.

Bureau de coordination

Le bureau de coordination est formé de l'ensemble des délégués.

Les réunions du bureau de coordination sont ouvertes à tout le collectif mais, en cas de vote pour ce bureau, seules les prises de positions des délégués seraient prises en compte.

En plus des pouvoirs légués à chaque délégué, le Bureau de coordination aurait des pouvoirs supplémentaires légués par le OVDPL.

Si assez membres du collectif devait remettre en cause une décision du Bureau, il leur est possible de la contester.

Secrétaire

Dans notre cas le secrétariat sera assurée par des outils informatiques et de algos choisis.

Sous-projets

Un sous-projet, tel que le 54, serait considéré comme un GT à part entière avec un délégué à part entière qui ne pourrait être destitué par un changement de OVDPL.

Cela car en tant que sous-projet, c'est néanmoins un projet à part entière que nous pourrions qualifier comme “version alpha”. Il y a donc directement paternité et possibilité de passer en tant que projet à part entière de l'association une fois l'autonomie atteinte.

Tout sous-projet aurait droit à une “chance” de deux ans avant de voir ce projet soumis à un vote du collectif pour voir s'il faut le continuer.

Tout sous-projet doit appliquer les mêmes règles de gouvernance que le projet auquel il est rattaché.

Dés le début, le chef d'un projet peut se voir comme le “Projet Leader” de son projet et cherchera à créer la même structure que celle du projet initial. Tant que le projet n'aura pas atteint son autonomie, toute modification du modèle sera la seule prise de décision ne pouvant être prise sans l'aval du projet principal ou tant qu'il ne sera pas passé en tant que projet à part entière auprès de l'association.

Les prises de décisions

Tout membre du collectif a le droit de remettre toute prise de décision en question.

Si nous partons des formules utilisées pour Debian, avec 12 membres, il faudrait 3 personnes pour lancer une “alerte de désaccord”, 3 autres les rejoignant dans ce désaccord pour lancer un vote et cinq votants seulement pour valider le désaccord au travers d'un vote.

En cas d'égalité, donc ici 6/6, le PL a un vote qui vaut double.

Ce moyen annule toute prise de décision proposée et ne peut être remis en cause. La proposition ne peut être imposée et doit être reformulée et retravaillée.


L'association

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é.