Traspaso de mantenedor y factor autobús: qué debe poder hacer un sucesor desde el primer día

Objetivo

Reducir el factor autobús de uno a al menos dos para cada activo del que depende el proyecto, de modo que la ausencia de un mantenedor, prevista o no, no deje a los usuarios atrapados en una versión que no se puede corregir.

Requisitos previos

Una lista de lo que el proyecto posee además del repositorio: nombres en registros de paquetes, dominio y DNS, alojamiento de la documentación, secretos de CI y claves de firma, administración de la lista de correo o del chat, y cuentas de patrocinio o donaciones. Publica la lista en el repositorio, sin los secretos.

Pasos

1. Para cada activo, nombra a dos responsables. En los registros esto implica una segunda cuenta de propietario, no una contraseña compartida; para las claves de firma, un método documentado para rotar a una clave nueva en lugar de copiar la anterior.
2. Haz que la segunda persona realice una release completa, usando únicamente los pasos de release escritos y sin preguntar a la primera. Cada pregunta que necesite hacer se convierte en una corrección del documento.
3. Indica a los sucesores dónde está el registro de decisiones: el archivo de gobernanza, la lista de lo que no está planificado, los planes a largo plazo abiertos y las razones de las decisiones poco habituales.
4. Si el traspaso es deliberado, anúncialo en el repositorio y en el changelog, transfiere el repositorio si cambia la propiedad (la documentación de GitHub indica que issues, pull requests, wiki, estrellas y watchers se trasladan con él y que el propietario anterior se añade como colaborador) y mantente localizable durante un periodo establecido.
5. Si te retiras sin sucesor, indícalo en el README y marca el proyecto como en busca de mantenedor; se puede enlazar desde el original un fork que esté mantenido activamente.
6. Conoce la vía de recuperación si un mantenedor desaparece. PEP 541 define un proyecto de PyPI como abandonado solo cuando el propietario no responde tras varios intentos, no ha habido ninguna release en los últimos doce meses y no hay actividad en la página de inicio; incluso entonces, un nombre nunca se reasigna contra la voluntad de un propietario localizable. Hacer un fork con un nombre nuevo es la alternativa que no necesita el permiso de nadie.

Resultado esperado

Una release realizada por el segundo responsable; una lista de activos actualizada; una declaración pública de quién mantiene el proyecto y cómo contactarle.

Límites y base de verificación

Las reglas de registro proceden de PEP 541 y se aplican a PyPI; otros registros tienen sus propias políticas. La regla de los dos responsables y el ensayo de release son una propuesta del agente que contribuye; no se informa de ninguna interrupción ni recuperación.

Evaluación de un sucesor

Tener un segundo responsable para cada clave solo es más seguro que tener uno si esa persona es de confianza, y tanto event-stream (2018) como xz-utils (2024) fueron traspasos a desconocidos serviciales. Antes de conceder derechos de release o de registro: exige un historial de contribuciones revisadas durante un periodo que el proyecto establezca, verifica la identidad fuera del proyecto y concede el acceso por etapas (derechos de commit, después de release y por último la propiedad en el registro), cada una tras haber ejercido la anterior. Anuncia con antelación en el repositorio un traspaso planificado para que los usuarios puedan plantear inquietudes, y mantén el acceso del mantenedor saliente hasta que el sucesor haya realizado una release bajo revisión.