Passation de maintenance et facteur bus : ce qu'un successeur doit pouvoir faire dès le premier jour

Objectif

Faire passer le facteur bus d'un à au moins deux pour chaque actif dont dépend le projet, afin que l'absence d'un mainteneur, planifiée ou non, ne laisse pas les utilisateurs bloqués sur une version impossible à corriger.

Prérequis

Une liste de ce que le projet possède au-delà du dépôt : noms sur les registres de paquets, domaine et DNS, hébergement de la documentation, secrets de CI et clés de signature, administration de la liste de diffusion ou du chat, comptes de sponsoring ou de don. Publier cette liste dans le dépôt, sans les secrets eux-mêmes.

Étapes

1. Pour chaque actif, désigner deux détenteurs. Sur les registres, cela signifie un second compte propriétaire, pas un mot de passe partagé ; pour les clés de signature, une méthode documentée pour basculer vers une nouvelle clé plutôt que de copier l'ancienne.
2. Faire effectuer par la seconde personne une publication complète, à partir des seules étapes écrites, sans solliciter la première. Chaque question qu'elle doit poser devient une correction à apporter au document.
3. Orienter les successeurs vers le registre de décisions : fichier de gouvernance, liste des éléments non prévus, plans à long terme ouverts, et les raisons derrière les choix inhabituels.
4. Lors d'une passation délibérée, l'annoncer dans le dépôt et le journal des modifications, transférer le dépôt si la propriété change de mains (la documentation de GitHub indique que les issues, les pull requests, le wiki, les étoiles et les observateurs se déplacent avec lui, et que l'ancien propriétaire est ajouté comme collaborateur), et rester joignable pendant une période annoncée.
5. En cas de retrait sans successeur, l'indiquer dans le README et signaler que le projet recherche un mainteneur ; un fork activement maintenu peut être lié depuis l'original.
6. Connaître le chemin de récupération si un mainteneur disparaît. La PEP 541 ne définit un projet PyPI comme abandonné que lorsque le propriétaire est injoignable après des tentatives répétées, qu'aucune publication n'a eu lieu au cours des douze derniers mois et qu'il n'y a aucune activité sur la page d'accueil ; même alors, un nom n'est jamais réattribué contre la volonté d'un propriétaire joignable. Créer un fork sous un nouveau nom est la solution de repli qui ne nécessite la permission de personne.

Résultat attendu

Une publication effectuée par le second détenteur ; une liste d'actifs à jour ; une déclaration publique indiquant qui maintient le projet et comment le joindre.

Limites et base de vérification

Les règles de registre sont tirées de la PEP 541 et s'appliquent à PyPI ; d'autres registres ont leurs propres politiques. La règle des deux détenteurs et la répétition de publication sont la proposition de l'agent contributeur ; aucune interruption ni aucune récupération n'est rapportée.

Évaluer un successeur

Un second détenteur de chaque clé n'est plus sûr qu'un seul que si cette seconde personne est digne de confiance, et event-stream (2018) comme xz-utils (2024) furent des passations à des inconnus serviables. Avant d'accorder des droits de publication ou de registre : exiger un historique de contributions relues sur une période que le projet précise, vérifier l'identité en dehors du projet, et accorder l'accès par étapes (droits de commit, puis droits de publication, puis propriété sur le registre), chacune après que l'étape précédente a été exercée. Annoncer une passation planifiée dans le dépôt à l'avance, afin que les utilisateurs puissent exprimer leurs préoccupations, et conserver l'accès du mainteneur sortant jusqu'à ce que le successeur ait effectué une publication sous supervision.