GitHub permite archivar pull requests: cómo ordenar la cola sin perder historial

Archivar pull requests en GitHub ahora puede delegarse a usuarios con rol de triaje, sin concederles permiso para cambiar código. Desde el 8 de octubre de 2026, los roles triage, write, maintain y admin pueden archivar y desarchivar una solicitud. Al archivarla, GitHub la cierra, bloquea comentarios y reacciones, la oculta de la vista pública y la conserva para administradores. Es útil para spam, duplicados o propuestas abandonadas; no conviene cuando el equipo todavía necesita debatir, revisar o reabrir el cambio.

La actualización reduce una fricción habitual en repositorios con muchas contribuciones: antes, el archivado estaba limitado a administradores. La decisión sigue necesitando una regla interna, porque desarchivar devuelve la conversación, pero no reabre automáticamente el pull request.

Qué cambió en GitHub el 8 de octubre

Hecho. GitHub anunció que las personas con rol de triaje o superior ya pueden archivar y desarchivar pull requests. La plataforma cita tres usos frecuentes: moderar spam, retirar duplicados y apartar propuestas abandonadas.

El cambio amplía la capacidad de moderación sin entregar acceso de escritura. Según GitHub, los roles habilitados son triage, write, maintain y admin. Esto permite que una agencia, empresa o proyecto abierto distribuya el mantenimiento de la cola sin convertir a todos los moderadores en administradores.

Qué ocurre al archivar un pull request

• El pull request se cierra automáticamente.
• La conversación queda en modo de solo lectura.
• Se bloquean comentarios, reacciones y comentarios automáticos nuevos.
• El pull request deja de ser visible públicamente.
• Los administradores del repositorio pueden seguir viéndolo.
• Al desarchivarlo se recuperan comentarios y reacciones, pero no se reabre el pull request.

Archivar no equivale a fusionar ni a borrar. El cambio propuesto no entra en la rama principal y el historial queda conservado bajo el acceso descrito por GitHub.

Cuándo conviene archivar

Spam o contenido abusivo

Si una propuesta no busca aportar código y solo añade publicidad, ruido o abuso, archivar evita nueva actividad y retira el contenido de la vista pública. Conserva una evidencia administrativa sin mantener abierta la conversación.

Duplicados confirmados

Cuando dos pull requests resuelven el mismo problema, el equipo puede conservar activo el mejor encaminado y archivar el duplicado. Antes de hacerlo, conviene enlazar ambos en un comentario o registro interno para no perder la relación.

Propuestas abandonadas sin camino de recuperación

Un cambio antiguo, incompatible con la arquitectura actual o sin responsable puede archivarse después de documentar por qué no continuará. Si todavía existe una posibilidad razonable de retomarlo, cerrar o etiquetar suele ser menos restrictivo.

Cuándo no conviene usar el archivo

• La revisión sigue activa: archivar bloquea nuevas aportaciones.
• El autor debe corregir algo: cerrar y comentar mantiene una ruta clara para continuar.
• El equipo necesita visibilidad pública: los pull requests archivados quedan ocultos para el público.
• Solo falta priorización: una etiqueta o un proyecto puede ser suficiente.
• Se pretende fusionar después: archivar cierra la solicitud; primero debe resolverse el flujo de revisión.

Un protocolo sencillo para agencias y equipos

1. Clasifica el motivo: spam, duplicado, abandonado o incumplimiento de las reglas de contribución.
2. Comprueba el estado: confirma que no haya revisión activa, dependencia técnica o entrega comprometida.
3. Deja trazabilidad: registra el motivo, el enlace a la alternativa y la persona responsable antes del archivo.
4. Aplica el mínimo permiso: usa el rol de triaje cuando la función sea moderar, no modificar código.
5. Revisa excepciones: define quién puede solicitar el desarchivo y quién decide si el pull request debe reabrirse.
6. Mide la cola: observa tiempo hasta la primera revisión, antigüedad y proporción de duplicados; no premies solo reducir el número visible.

Cómo se relaciona con otros flujos de GitHub

El archivo resuelve moderación y limpieza, pero no sustituye una estrategia de revisión. Para cambios grandes, la guía sobre pull requests apiladas en GitHub explica cómo dividir trabajo sin perder dependencias.

Tampoco reemplaza controles de seguridad. Si el repositorio ejecuta automatizaciones con código aportado por terceros, revisa los límites de pull_request_target en GitHub Actions. Para integraciones, el artículo sobre tokens de GitHub Apps ayuda a comprobar formatos y compatibilidad antes de una migración.

Oportunidades y precauciones

Análisis. La oportunidad principal es separar moderación de administración. Un colaborador de confianza puede mantener ordenada la cola sin permiso para escribir en el repositorio. Eso reduce esperas y aplica el principio de mínimo privilegio.

Precaución. Ocultar una propuesta pública puede afectar la transparencia si no existe una política clara. En proyectos abiertos, publica criterios de moderación y usa el archivo solo para casos definidos. No lo conviertas en una vía para silenciar críticas técnicas o cerrar discusiones legítimas.

Recomendación. Durante las primeras semanas, revisa cada archivo de forma manual. Si el volumen justifica automatización, limita cualquier regla automática a señales claras y conserva una revisión humana para falsos positivos.

Preguntas frecuentes

¿Quién puede archivar pull requests?

Desde el 8 de octubre de 2026, GitHub habilita los roles triage, write, maintain y admin.

¿Archivar elimina el pull request?

No. Lo cierra, vuelve su conversación de solo lectura y lo oculta de la vista pública; los administradores conservan acceso.

¿Desarchivar vuelve a abrir la propuesta?

No. Desarchivar restaura la posibilidad de comentar y reaccionar, pero la solicitud permanece cerrada hasta que alguien la reabra mediante el flujo correspondiente.

¿Es mejor archivar o cerrar?

Cierra cuando todavía necesitas que el historial sea público o que el autor pueda continuar la conversación. Archiva cuando el caso debe quedar congelado y fuera de la vista pública, por ejemplo spam o un duplicado definitivo.

¿El rol de triaje puede modificar código?

La finalidad del cambio es permitir moderación sin otorgar permisos de escritura. Los permisos efectivos dependen de la configuración del repositorio y deben revisarse antes de asignar el rol.

Fuentes y verificación

• GitHub Changelog: Triage role users or higher can now archive pull requests, 8 de octubre de 2026.
• GitHub Docs: roles de repositorio para organizaciones, consultado el 9 de octubre de 2026.

Verificado el 9 de octubre de 2026 a las 03:18, America/Lima. GitHub puede modificar funciones y permisos; confirma el comportamiento en la documentación y en un repositorio de prueba antes de aplicarlo a proyectos críticos.