La communauté Python adopte un nouveau modèle de gouvernance
La communauté Python adopte un nouveau modèle de gouvernance,
cinq mois après le départ volontaire du créateur du langage qui en était le décisionnaire
Guido van Rossum est le créateur du langage Python. Récemment, il jouait le même rôle que Linus Torvalds pour le noyau Linux puisqu'il était le décisionnaire en dernier ressort (le BDFL : Benevolent Dictator For Life) de toutes les modifications qui étaient incluses dans Python. En effet, mi-juillet, alors lors qu'il ventait de valider la 572e proposition d'amélioration de Python, il a décidé d'arrêter de prendre part au processus de validations de ces PEP. Dans un mail adressé à la communauté, le BDFL a déclaré :
Le hic ? La communauté n’était pas préparée à ce changement dans son organisation. Il leur a laissé le libre choix de décider de leur avenir.Envoyé par Guido van Rossum
Guido van Rossum
La question de la gouvernance
Au cours des trois mois qui ont suivi, des efforts ont été fournis dans la recherche de cette nouvelle gouvernance avec une difficulté supplémentaire : il n’existait pas de mécanisme permettant de choisir le mode de sélection d’un nouveau modèle de gouvernance.
Comme pour presque tous les changements importants pour Python, la question de la gouvernance a été scindée en une série de propositions d’amélioration de Python (PEP). Dans ce cas, PEP 8000 est une vue d'ensemble (ou un index) des différents PEP considérés.
À la date du 24 octobre 2018, il y avait six propositions, bien qu'il y ait beaucoup de chevauchement entre elles de différentes manières. Les PEP 8010 à 8015 constituaient alors les propositions que les développeurs principaux devaient choisir.
Le grand vainqueur
Ce n’est qu’en novembre que le dispositif de vote a enfin pu être mis en place. Les électeurs avaient donc une période de deux semaines, qui s’est achevée le 1er décembre, pour choisir leur gouvernance parmi les six propositions. La méthode qui a été retenue pour choisir le vainqueur était IRV (instant-runoff voting). Au final, le vote s’est achevé le 16 décembre 2018 et un gagnant a été déclaré : le PEP 8016, qui propose un modèle du conseil de direction.
Dans le résumé de sa proposition, nous pouvons lire
Les principaux objectifs de cette proposition sont les suivants :
Le conseil de direction du PEP 8016 est composé de cinq personnes élues par l'équipe principale. La définition de l’équipe principale est quelque peu différente de celle des principaux développeurs. Le PEP indique explicitement que des rôles autres que « développeur » pourraient être qualifiés pour figurer parmi l'équipe principale. Devenir membre de l'équipe nécessite simplement un vote à la majorité des deux tiers des membres existants - et sans veto du conseil de direction.
Fonctionnement du conseil de direction Python
Le conseil est doté d'un « large pouvoir pour prendre des décisions concernant le projet », mais l'objectif est qu'il l'utilise rarement; il est destiné à déléguer son autorité. Le PEP dit que le conseil devrait rechercher un consensus plutôt que d’imposer et qu'il devrait définir un processus de prise de décision standard du PEP qui aura rarement besoin des votes du conseil pour le résoudre. Il s’agit toutefois du « tribunal d’appel final » pour les décisions concernant le langage. Mais le conseil ne peut pas changer la gouvernance PEP; cela ne peut se faire que par un vote aux deux tiers de l'équipe principale.
Les membres du comité de direction serviront pendant toute la durée de la sortie d'une seule fonctionnalité Python. Après chaque publication, un nouveau conseil sera élu. Les candidats doivent être nommés par un membre essentiel de l'équipe. Un « vote d'approbation » sera utilisé pour choisir le nouveau conseil. Chaque membre de l’équipe centrale peut voter anonymement pour zéro à cinq des candidats; les cinq qui obtiendront le plus grand nombre de voix au total siègeront au nouveau conseil. En cas d’égalités, la décision finale sera prise par accord entre les candidats ex aequo ou par choix aléatoire.
Il existe également certaines règles relatives aux conflits d’intérêts : « Même si nous faisons confiance aux membres du conseil pour agir dans l’intérêt supérieur de Python plutôt que pour eux-mêmes ou leurs employeurs, la simple apparence d’une société dominant le développement de Python pourrait elle-même être préjudiciable et éroder la confiance ». Donc, il n’est pas permis à plus de deux membres du conseil de provenir de la même entreprise; si un troisième membre d’une même société venait à être élu, ils seront automatiquement disqualifiés et le prochain groupe va simplement progresser. Si la situation se présente pendant le mandat du conseil (par exemple, un changement d’employeur ou une acquisition), un nombre suffisant de membres du conseil doit démissionner pour assurer cette composition. Les postes vacants au conseil (pour cette raison ou pour toute autre raison) seront pourvus par un vote du conseil.
En cas de mécontentement de l’équipe centrale à l’égard du conseil, un vote de censure peut être organisé. Un membre de l'équipe principale peut demander un tel vote. Si un autre membre se montre en faveur de l'appel, un vote est tenu. Le vote peut cibler un seul membre du conseil ou le conseil dans son ensemble. Si les deux tiers des membres de l’équipe centrale votent pour un vote sans confiance, le conseiller ou le conseil est destitué. Dans ce dernier cas, une nouvelle élection du conseil est immédiatement déclenchée.
Exemple d'un autre modèle de gouvernance : cas de Fedora
Le projet Fedora est un projet communautaire gouverné par deux groupes de personnes : le conseil et le FESCo (abréviation de Fedora Engineering Steering Committee). Le conseil est composé de dix personnes. Outre le président, il s’agit du groupe ayant le droit de veto sur le projet. Le conseil est composé de quatre membres nommés par le président et cinq autres élus par la communauté Fedora. Le conseil prend des décisions sur les aspects stratégiques et financiers du projet. Le FESCo, ou comité de pilotage technique, est responsable des travaux de développement techniques du projet. Le FESCo se compose de neuf personnes élues par la communauté Fedora. Les discussions et les décisions des deux organes sont majoritairement faites en ligne via IRC et sont accessibles publiquement. En tant que chef de projet Fedora, FPL pour Fedora Project Leader, le président du conseil doit coordonner les décisions du conseil et celles du FESCo.
Le projet est également gouverné par cinq sous-groupes de travail indépendants réparti sur Base Design, Environments and Stacks, Fedora Server, Fedora Workstation et Fedora Atomic.
Les SIG, Special Interest Groups, sont des équipes au sein du Projet Fedora qui sont moins formelles que les sous-projets officiels. Les SIG sont parfois une première étape dans le développement de nouveaux projets au sein du projet Fedora.
Source : annonce de la gouvernance gagnante, PEP 8016, courrier du créateur de Python annonçant sa démission
Et vous ?
Que pensez-vous de ce modèle de gouvernance ?
Voir aussi :
Répondre avec citation
Partager