La gouvernance d'un petit projet : des droits de décision écrits avant d'en avoir besoin

Ce que c'est

La gouvernance est l'ensemble des règles qui indiquent qui peut décider de quoi, et comment une décision est reconnue comme prise. Trois formes couvrent la plupart des petits projets. Un mainteneur unique décide de tout et le dit. Un petit groupe décide par consensus tacite, que le glossaire d'Apache définit comme une politique qui suppose un consentement général si aucune réponse n'est postée dans un délai défini, avec un vote explicite réservé aux questions contestées. Un conseil détient l'autorité finale : la PEP 13 dote Python d'un conseil directeur de cinq personnes doté d'une large autorité que le document dit vouloir exercer aussi rarement que possible, préférant le consensus et les processus standards aux décisions tranchées, votant à la majorité stricte des membres non abstentionnistes, et délibérant publiquement chaque fois que possible.

Pourquoi c'est important

Sans règles écrites, les désaccords se règlent au profit de qui parle le plus fort ou par le silence, les contributeurs ne peuvent pas savoir si une proposition est approuvée ou simplement non contestée, et une passation n'a aucune base sur laquelle s'appuyer. Les règles comptent le moins les jours ordinaires et le plus le jour où deux mainteneurs sont en désaccord sur l'API publique.

Comment l'appliquer

• Écrire un fichier GOVERNANCE d'une page : les mainteneurs par nom et par domaine ; qui peut fusionner quoi ; la règle de décision par défaut (consensus tacite avec un délai fixé pour les changements courants, accord explicite de tous les mainteneurs pour l'API publique, la licence, le périmètre et l'ajout d'un mainteneur).
• Nommer un mécanisme de départage pour le cas de deux mainteneurs : un responsable de domaine par module, ou un dernier mot tournant, décidé maintenant plutôt que pendant un désaccord.
• Définir comment un mainteneur est ajouté (proposition, délai, accord) et comment il devient inactif ou est retiré, y compris le cas d'un mainteneur injoignable.
• Consigner les décisions là où elles ont été prises : le fil de l'issue ou de la pull request, et un registre de décision d'architecture (ADR) pour tout ce qui façonne la base de code.
• Garder la délibération publique, comme la PEP 13 l'exige de son conseil chaque fois que possible ; une décision privée doit être publiée ensuite avec ses raisons.
• Ne laisser le fichier s'amender que selon sa propre règle, et dater chaque changement.

Pièges

Copier une structure de conseil pour deux personnes. Des règles écrites et jamais appliquées, si bien que leur premier usage réel en est aussi le premier test. Le silence traité comme un consentement sans délai fixé, ce qui fait passer une proposition parce que personne ne l'a lue. Une gouvernance qui nomme des personnes mais pas des domaines, si bien que toute question remonte au fondateur.