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é :
Envoyé par Guido van Rossum
Maintenant que la PEP 572 est acceptée, je ne veux plus avoir à me battre autant pour une proposition de modification, surtout si autant de gens méprisent ma décision
Je voudrais me retirer complètement du processus de décision. Je serai toujours là pendant un moment en tant que développeur ordinaire, et je serai toujours disponible pour encadrer des personnes - peut-être davantage. Mais je me donne essentiellement des vacances permanentes en tant que BDFL, et vous serez tous seuls.
Après tout, cela devait finir par arriver - il y a toujours ce bus qui se cache au coin de la rue, et je ne rajeunis pas ... (je vous épargne la liste des problèmes médicaux.)
Je voudrais me retirer complètement du processus de décision. Je serai toujours là pendant un moment en tant que développeur ordinaire, et je serai toujours disponible pour encadrer des personnes - peut-être davantage. Mais je me donne essentiellement des vacances permanentes en tant que BDFL, et vous serez tous seuls.
Après tout, cela devait finir par arriver - il y a toujours ce bus qui se cache au coin de la rue, et je ne rajeunis pas ... (je vous épargne la liste des problèmes médicaux.)
Envoyé par Guido van Rossum
Je ne vais pas nommer un successeur.
Alors qu'est-ce que vous allez tous faire ? Créer une démocratie ? L'anarchie ? Une dictature ? Une fédération ?
Alors qu'est-ce que vous allez tous faire ? Créer une démocratie ? L'anarchie ? Une dictature ? Une fédération ?
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
Envoyé par PEP 8016
Ce PEP propose un modèle de gouvernance Python basé sur un modèle de conseil de direction. Le conseil a un large pouvoir qu’il cherche à exercer le plus rarement possible; au lieu de cela, il utilise ce pouvoir pour établir des processus standard, comme ceux proposés dans les autres PEP de la série 801x. Cela correspond à la philosophie générale selon laquelle il est préférable de scinder de gros changements en une série de petits changements pouvant être examinés indépendamment: au lieu d'essayer de tout faire dans un PPE, nous nous concentrons sur la fourniture d'une base minimale, mais solide pour de futures décisions de gouvernance.
Les principaux objectifs de cette proposition sont les suivants :
Envoyé par PEP 8016
- Être ennuyeux : nous ne sommes pas des experts en gouvernance et nous ne pensons pas que Python soit un bon endroit pour expérimenter de nouveaux modèles de gouvernance. Cette proposition s’inscrit donc autant que possible dans des processus éprouvés, bien connus et ayant fait l’objet de tests préalables. L'approche de haut niveau d'un conseil essentiellement actif est sans doute la plus courante parmi les grands projets réussis de F / OSS, et les détails de bas niveau sont directement dérivés de la gouvernance de Django.
- Être simple : nous avons essayé de réduire au minimum les éléments nécessaires pour rendre cette opération viable: le conseil, l'équipe principale (qui élit le conseil) et le processus de modification du document. L'objectif est la gouvernance minimale viable.
- Être compréhensif : mais pour les choses que nous devons définir, nous avons essayé de nous assurer de couvrir toutes les bases, car nous ne voulons plus traverser ce genre de crise. Disposer d'un ensemble de règles claires et non ambiguës aide également à réduire la confusion et le ressentiment.
- Être flexible et léger : nous savons qu'il faudra du temps et des expériences pour trouver les meilleurs processus pour travailler ensemble. En minimisant le plus possible ce document, nous gardons une flexibilité maximale pour ajuster les choses plus tard, tout en minimisant le recours à des processus lourds et angoissants, tels que les votes pour l'ensemble du projet.
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,...
La fin de cet article est réservée aux abonnés. Soutenez le Club Developpez.com en prenant un abonnement pour que nous puissions continuer à vous proposer des publications.
