Résumé

  • La Charte du Cross Project Council prévoit qu’à partir du cycle électoral de l’automne 2026, les représentants votants non-Impact et les représentants des membres réguliers seront remplacés par au plus cinq Community Voting Members.
  • Cette catégorie n’est ni une simple présence aux réunions ni le statut de membre régulier : les candidats doivent être Regular Members sans représenter un projet Impact, tandis que l’électorat réunit les Voting Members des projets Impact et les Regular Members.
  • Un relevé de transition devrait relier l’ancien siège, la nouvelle catégorie, la base de l’électorat, le résultat, la durée, le contrôle d’affiliation et les compétences respectives du Board, du CPC et des projets.

Une règle future n’est pas un résultat électoral

Dans une fondation de logiciel libre, les documents constitutifs circulent plus vite que l’état qu’ils annoncent. Une modification de Charte est visible, une rubrique de site est actualisée, une réunion est ouverte : ce sont des informations utiles. Elles ne disent pas encore qu’une élection a eu lieu, qu’une personne était éligible, que le dépouillement a été clos ou qu’un siège est entré en fonction.

Le cas d’OpenJS est précis. La Charte présente le Cross Project Council, le CPC, comme la direction technique de la Fondation, distincte du Board, sa direction d’affaires. Le Board fixe le cadre général des politiques du CPC. Le CPC traite les questions techniques qui lui sont déléguées, dans ce cadre. À partir du cycle de l’automne 2026, la Charte prévoit de remplacer les deux voies de vote non liées aux projets Impact par une catégorie unifiée de Community Voting Members.

C’est une réforme annoncée, pas une preuve qu’un scrutin a déjà produit une composition. À la date de référence de cette enquête, les sources publiques décrivent un cycle futur. Elles ne démontrent ni l’ouverture des candidatures, ni la liste des électeurs, ni le nombre de sièges effectivement pourvus, ni l’identité des élus. Cette différence de temps n’est pas une réserve de style : elle détermine ce qu’un lecteur peut vérifier.

Après la transition, un contributeur devrait pouvoir retrouver, sans dépendre de souvenirs internes, l’état de chaque voie antérieure. Le représentant a-t-il achevé son mandat, démissionné, perdu son éligibilité, été remplacé, ou est-il resté Regular Member sans devenir Community Voting Member ? Combien des cinq sièges possibles ont été remplis ? Quel était le nombre d’électeurs admissibles ? Le plafond d’affiliation par employeur a-t-il été calculé sur l’ensemble pertinent des Voting Members ? Et quelle décision dépend du Board, du CPC ou d’un projet autonome ?

Ces questions ne présument aucune irrégularité. Elles empêchent seulement qu’une page de liste soit relue plus tard comme un transfert implicite de pouvoir.

Présence, qualité de membre, électorat et siège : quatre réalités

La Charte distingue Observers, Regular Members et Voting Members. Le dépôt public du CPC indique que des non-membres peuvent assister aux réunions comme observateurs. Sa gouvernance définit ensuite comment un OpenJS Collaborator actif peut demander le statut de Regular Member. Le nouveau scrutin utilise encore une catégorie plus étroite : Impact Project Voting Members et Regular Members composent l’électorat des Community Voting Members.

Un Observer peut assister aux travaux publics et contribuer à la recherche d’un consensus. C’est une forme réelle de participation. Ce n’est ni un droit de vote ni une inscription automatique sur une liste électorale.

Un Regular Member possède une qualité institutionnelle différente. Les règles demandent déjà une activité récente et durable dans un projet, une communauté, un espace de collaboration ou les travaux du CPC. Elles prévoient une procédure d’examen. Cette qualité est nécessaire pour être candidat à la nouvelle catégorie et elle entre dans son électorat. Elle ne démontre toutefois pas que la personne a été élue.

Un Impact Project Voting Member provient d’une autre source. Chaque projet Impact peut proposer jusqu’à deux représentants suivant son propre processus. Cette classe subsiste dans la nouvelle architecture, et ses nominations passent par l’annonce prévue dans le dépôt. Le fait que ses membres participent à l’élection des Community Voting Members ne transforme pas leur propre siège en siège communautaire.

Un Community Voting Member, enfin, est une catégorie de vote définie pour le cycle à venir. Il peut y en avoir cinq au maximum. Le candidat doit être Regular Member et ne pas déjà représenter un projet Impact. Dire que « la communauté a voté » peut ainsi masquer quatre choses différentes : qui a parlé en réunion, qui était Regular Member, qui avait le droit de voter et qui a réellement reçu un siège. La Charte établit les deux premières frontières à l’avance ; le résultat devra documenter les suivantes.

La note de Heng Lu sur le mirage multi-parties prenantes apporte ici une discipline utile. La participation apporte des connaissances, des objections et des signaux. Elle ne fabrique pas, par elle-même, un mandat de principal sur tous ceux qui subiront une décision. Une réunion CPC ouverte ou une élection interne sont des preuves d’un processus défini au sein de la Fondation, non un mandat général sur l’écosystème JavaScript.

Le vote CPC ne remplace pas les autres autorités

La nouvelle catégorie ne redessine pas tous les pouvoirs autour du CPC. Les Voting Members exercent les responsabilités finales que la Charte confie au CPC ; celui-ci cherche d’abord le consensus et dispose d’une procédure de vote lorsque les objections ne se résolvent pas. Le Board conserve la politique générale, des prérogatives notamment juridiques et son rôle dans l’approbation des changements de Charte. Les projets gardent leurs propres processus documentés de décision technique dans les lignes directrices du CPC.

Ces niveaux se croisent sans devenir identiques. Un CPC Director peut représenter les projets et communautés de la Fondation auprès du Board ; une charte de projet peut requérir l’accord du CPC ; une proposition technique peut appeler une escalade vers le Board. Un Community Voting Member n’est donc pas automatiquement administrateur du Board, porte-parole de tous les mainteneurs ou décideur interne d’un projet. Le relevé doit nommer la capacité effectivement exercée.

La gouvernance du CPC laisse déjà plusieurs traces : une issue publique au début des candidatures, une pull request qui met à jour le README après l’élection, une note de résultat dans une liste privée, des ordres du jour et des comptes rendus. Elle reconnaît aussi des limites légitimes de confidentialité pour les sujets personnels, juridiques ou certains échanges avec le Board. La transparence ne suppose pas de publier chaque dossier ; elle exige de relier les faits décisifs qui sont publics.

Cette liaison est nécessaire. Un nom ajouté au README ne donne pas forcément la date de mandat, le sort d’un siège précédent ni le dénominateur électoral. Les règles précisent qu’un Voting Member dont le mandat vient de se terminer devient normalement Regular Member, sauf indication contraire. C’est un état par défaut utile, pas le récit complet d’un départ individuel. De même, « jusqu’à cinq » ne dit pas combien de sièges ont été remplis. Et le plafond d’un quart de membres votants affiliés au même employeur n’est pas reproductible sans effectif total daté et méthode d’affiliation.

Le relevé de transition proposé

Daniel Kade propose un relevé de transition des Community Voting Members. Il ne modifie pas la Charte et ne demande pas de rendre publics les dossiers privés de candidature. Il rassemble les faits que le lecteur devra sinon recomposer entre issues, listes, ordres du jour et changements de dépôt.

Le premier champ est l’état du cycle : « réforme prévue », « candidatures ouvertes », « scrutin en cours », « résultat certifié » ou « correction ». Il doit citer la formulation de la Charte, nommer l’ancienne et la nouvelle catégorie et empêcher qu’une règle au futur soit lue comme une nomination achevée.

Le deuxième est la carte des sièges. Elle donne, pour chaque voie concernée, la source du siège, le titulaire lorsqu’il est public, l’échéance habituelle et l’état de sortie : mandat achevé, démission, remplacement, retour au statut de Regular Member, candidature au nouveau siège ou état non publié. Pour les nouveaux sièges, elle indique lequel des cinq sièges possibles est rempli ou non. L’absence d’un nom ne doit jamais être transformée, par défaut, en vacance.

Le troisième champ couvre l’éligibilité et l’électorat. Il rappelle la condition de candidature et les deux catégories électorales prévues par la Charte. Il publie un total daté ou, si nécessaire, une méthode d’audit interne conservée. Il ne doit pas dévoiler une explication privée pour chaque personne ; il doit permettre de comprendre le dénominateur du résultat.

Le quatrième relie procédure et résultat : issue de nomination, méthode de vote effectivement employée lorsqu’elle est publiée, note de résultat, pull request du README, date d’effet et liste de Voting Members qui en résulte. La Charte mentionne notamment Condorcet et le vote unique transférable comme méthodes possibles. Le relevé doit enregistrer le choix réel, sans déduire une méthode d’une règle générale.

Le cinquième est le contrôle de composition : nombre total de Voting Members à la date d’effet, base publique d’affiliation si elle existe, plafond d’un quart et statut — respecté, corrigé, en attente ou non publié. Il s’agit de vérifier une condition posée par la Charte, non de suggérer un conflit.

Le dernier champ est une limite d’autorité et un journal de corrections. Il sépare Board, CPC, Directors et autonomie des projets ; il indique les éléments que les sources publiques ne démontrent pas. Toute rectification devient alors un ajout daté au relevé, plutôt qu’une modification silencieuse d’une liste.

La bonne gouvernance ouverte ne veut pas dire que chaque participant possède tous les pouvoirs. Elle veut dire que chaque pouvoir réel a une source, une portée et une fin lisibles. L’automne 2026 donne à OpenJS l’occasion de rendre cette distinction vérifiable au moment où elle se produit.

Sources

  1. Charte du Cross Project Council d’OpenJS
  2. Gouvernance du Cross Project Council d’OpenJS
  3. Dépôt et liste actuelle du Cross Project Council
  4. Archives Governance d’OpenJS Foundation
  5. Lu Heng — Le mirage multi-parties prenantes