GitHub permite que el rol Triage archive pull requests, y no solo los administradores

El 8 de octubre de 2026, GitHub cambió las reglas de acceso para archivar pull requests. Ahora pueden archivarlos y desarchivarlos los usuarios con rol Triage o superior. Hasta entonces, ese permiso era exclusivo de los administradores del repositorio. De los cinco roles estándar de GitHub (Read, Triage, Write, Maintain, Admin), el umbral ha bajado del escalón más alto al segundo por abajo. Es un cambio pequeño en uno de los flujos de trabajo más concurridos de la plataforma.

Qué ha cambiado exactamente

El anuncio en el GitHub Changelog es breve. Antes, archivar un PR exigía permisos de administrador, así que los triagers de confianza tenían que pasar a los administradores incluso los casos rutinarios. El texto del anuncio, en la versión a la que hemos tenido acceso, se interrumpe en esa frase. No incluye detalles de implementación, por ejemplo cómo se muestran los PR archivados en la búsqueda y los filtros, o qué eventos quedan registrados en el registro de auditoría. Conviene consultarlos en la documentación de GitHub.

La regla ahora funciona en ambos sentidos: un usuario con rol Triage puede tanto mover un PR al archivo como devolverlo. Es un detalle importante. Si un triager archiva algo por error, lo corrige él mismo y no tiene que buscar a un administrador.

Por qué importa el umbral de acceso

El rol Triage de GitHub se creó para quienes gestionan el flujo entrante. Asignan etiquetas, designan responsables, cierran duplicados y reabren tareas. Eso sí, no pueden hacer push de código al repositorio. Es un rol natural para voluntarios en proyectos abiertos y para ingenieros de soporte o especialistas de QA en equipos corporativos.

Antes del cambio había un vacío. El triager veía un PR obsoleto o abandonado y podía cerrarlo, pero no retirarlo del espacio de trabajo. Para eso tenía que escribir a un administrador. En los proyectos pequeños suele haber un solo administrador, y esas peticiones se convierten rápidamente en un cuello de botella. Ahora la limpieza rutinaria de la cola se queda en el nivel en el que se toman las decisiones sobre su contenido.

Hay además un trasfondo indirecto. Herramientas como los agentes de programación abaratan la apertura de PR, y en muchos repositorios las colas crecen. GitHub no menciona esta relación en su anuncio; es una observación nuestra. Pero cuantos más PR se crean de forma automática, más cara resulta cada transferencia innecesaria de una tarea entre roles.

Los parámetros en breve

• Fecha del anuncio: 8 de octubre de 2026.
• Quién tiene acceso: rol Triage y superiores (Triage, Write, Maintain, Admin).
• Operaciones: archivar y desarchivar pull requests.
• Antes: solo los administradores del repositorio.
• Fuente: GitHub Changelog.

Cómo aprovechar el cambio en el equipo

Primero, revisa a quién se le ha asignado el rol Triage en tu repositorio. Si lo repartiste solo para gestionar etiquetas y asignaciones, esas personas tienen ahora una acción más. Para la mayoría de los equipos es aceptable, pero en proyectos con un reglamento estricto conviene avisar de antemano.

Después, deja por escrito en CONTRIBUTING o en una guía interna los criterios de archivado. Por ejemplo: PR sin actividad durante más de un plazo determinado, duplicados, PR abandonados por su autor. Sin una regla, cada triager decidirá de forma distinta y las preguntas del tipo «por qué ha desaparecido mi PR» serán más frecuentes.

Por último, si tienes automatización en torno a los PR (bots, dashboards, informes de velocidad de revisión), comprueba cómo tratan las solicitudes archivadas. Los desarrolladores que miden el tiempo de vida de los PR deberían decidir de antemano si el archivado cuenta como cierre. Es poco probable que GitHub indique cómo hacerlo en tu proceso concreto.