Résumé

  • Les règles d'Apache séparent le veto qualifié sur une modification de code, le vote de publication d'un paquet et la surveillance corporative du Board.
  • Un reçu d'autorité doit relier l'action, l'artefact, le collège ayant voix contraignante, la règle, les objections et l'éventuel acte corporatif, sans les confondre.

Le mot « approuvé » efface trop facilement l'action réelle

Dire qu'« Apache a approuvé » quelque chose peut désigner un commit, une discussion de liste, une publication, une décision de PMC, une résolution du Board ou la simple lecture d'un rapport trimestriel. Les pages de gouvernance de la Foundation distribuent précisément ces rôles. Leur sens pratique est de laisser l'autonomie technique au projet tout en gardant une responsabilité juridique et des moyens de surveillance au niveau de la Foundation.

Il faut donc partir de l'objet décidé. Une modification de code n'est pas une publication. Une publication n'est pas une nomination d'officier. Une question posée par un directeur n'est pas une instruction technique du Board. Une même personne peut porter plusieurs titres, mais le titre ne remplace pas la règle applicable à l'acte.

Écrire dans le dépôt ne rend pas une publication officielle

Le guide des PMC dit que les committers peuvent mettre à jour le code, tandis que seul le PMC, comme corps, peut voter sur les publications formelles du logiciel. Ce n'est pas un jugement sur la valeur d'un committer. C'est une séparation entre l'accès technique au dépôt et l'acte institutionnel qui présente un artefact comme publication Apache.

Une publication doit donc désigner l'artefact précis : candidat, révision source, signature, empreinte ou identifiant final. Un compte de votes sans objet stable ne permet pas de savoir quel logiciel a été retenu. Inversement, le vote ne démontre ni que chaque ligne a été rediscutée par le Board, ni que tous les utilisateurs adopteront l'artefact.

Le veto de code est puissant, mais il a une portée définie

La procédure de vote distingue les questions procédurales, les modifications de code et les publications de paquets. Hors lazy consensus, une modification de code requiert trois +1 et aucun -1. Un -1 d'un votant qualifié constitue un veto : il doit comporter une justification technique et ne peut être écarté tant que son auteur ne le retire pas.

Cette force ne transforme pas chaque commentaire négatif en arrêt universel. Il faut l'action de modification concernée, le groupe compétent et un votant qualifié. Un veto valable appelle la conservation de la proposition, de sa version, de la raison technique, de la discussion et de la suite donnée. Il ne crée pas, à lui seul, une politique corporative ni une décision de marché.

La publication suit une autre règle

Pour une publication de paquet, Apache indique au moins trois +1 contraignants et davantage de positifs que de négatifs contraignants. La même page précise que les publications ne peuvent pas être vetoées. Ce n'est pas une atténuation du veto de code : c'est un test différent pour une autre décision.

Il serait donc inexact d'écrire qu'un -1 a « vetoé la publication » sans identifier la règle appliquée. Un -1 peut viser une modification, exprimer un avis non contraignant ou appartenir à une discussion antérieure. À l'inverse, une publication adoptée ne fait pas disparaître les objections techniques. Elle établit seulement le statut formel de l'artefact selon la règle de publication.

Le PMC dirige le projet; le Board tient le cadre corporatif

Les PMC définissent la direction technique et communautaire de leurs projets, organisent les publications et répondent aux exigences centrales de la Foundation. Le Board crée les PMC, nomme les Vice Presidents/Chairs, gère les actifs et les politiques générales, reçoit les rapports et peut agir lorsqu'un PMC dysfonctionne. Mais les documents ASF disent aussi que le Board ne donne pas de direction technique aux projets.

Les directeurs n'obtiennent pas automatiquement un droit de commit, une place au PMC ou une voix technique contraignante. Pour influencer un projet comme participant technique, ils doivent gagner le mérite propre à ce projet. De même, les Members élisent les directeurs, mais ne reçoivent pas par ce seul statut une compétence spéciale sur la direction technique des projets.

La présidence du PMC relie sans les fusionner les deux registres. Le Chair a une voix ordinaire au sein du PMC, tout en étant l'officier chargé des rapports et du registre officiel du PMC. Un choix interne de changer de Chair exige ensuite une résolution du Board pour devenir une nomination officielle.

Un reçu de publication et d'autorité

Pour une modification de code, le reçu devrait désigner le changement, le canal de revue, la règle, les votants qualifiés, les positions explicites et la justification d'un veto valable, sans publier des éléments privés de sécurité ou de personnel.

Pour une publication, il devrait fixer l'artefact, le projet, le PMC, la fenêtre de décision, la règle des votes contraignants, le résultat, les observations non contraignantes et l'identifiant de publication. Pour un acte corporatif, il devrait dire séparément s'il s'agit d'une résolution, d'une nomination, d'une demande ou de la lecture d'un rapport. Deux événements liés doivent rester deux preuves.

Ce reçu n'est pas une nouvelle obligation Apache proposée comme règle existante. C'est une recommandation éditoriale pour empêcher les mots « veto », « publication », « PMC » et « Board » d'acquérir une autorité qu'ils n'ont pas dans le dossier concerné.

Sources

  1. Apache Corporate Governance — PMCs
  2. Apache Voting Process
  3. Apache Project Management Committee Guide
  4. Apache Corporate Governance — Board of Directors
  5. Apache Corporate Governance — Members
  6. Lu Heng, The Multi-Stakeholder Mirage