GitHub empieza a contar los pull request en borrador dentro de los límites de PR abiertos

El 8 de octubre de 2026, GitHub amplió la configuración de los límites de pull request: ahora se pueden configurar para que también cuenten los PR en borrador (draft). El anuncio en GitHub Changelog es breve y el motivo se expone sin ambages: los mantenedores ven en sus repositorios cada vez más contribuciones de baja calidad y necesitan mejores formas de gestionarlas. El anuncio no incluye cifras, pero el cambio tiene una lógica clara.

Qué ha cambiado exactamente

Los límites de pull request permiten a los propietarios de repositorios restringir el número de PR abiertos al mismo tiempo. Por la fórmula «ahora también se pueden incluir los borradores», hasta ahora los draft no entraban en esas restricciones. Para un autor que quisiera esquivar el límite, era una laguna a medida: bastaba con abrir preparativos en estado draft y acumularlos sin tope.

Ahora esa brecha se puede cerrar, y de forma opcional. La configuración no se impone a todos los proyectos: es el mantenedor quien decide si los borradores cuentan igual que los PR normales.

De dónde viene el ruido

El flujo de contribuciones débiles en el código abierto lleva tiempo siendo un problema por sí mismo. Una parte de estas solicitudes surge de ediciones masivas para engordar estadísticas o un «portfolio». Cada vez más las generan asistentes de código y agentes, capaces de abrir un PR más rápido de lo que una persona tarda en leer la descripción. GitHub no detalla las causas en su anuncio, pero el contexto del sector es evidente: el coste de crear un PR ha caído casi a cero, mientras que el coste de revisarlo sigue igual y recae por completo en el mantenedor.

En este esquema, el borrador funciona como un búfer. Un autor, o su script, puede mantener decenas de preparativos abiertos, y el mantenedor los sigue viendo en la lista, recibe notificaciones y gasta atención en clasificarlos. Incluir los draft en el límite hace la regla más justa: una solicitud abierta ocupa un hueco independientemente de su estado.

Qué se sabe de los parámetros

• Fecha de publicación: 8 de octubre de 2026, sección GitHub Changelog.
• Esencia: los draft pull request se pueden incluir en el cómputo de los límites de PR.
• Tipo de ajuste: opcional, gestionado por los mantenedores.
• Objetivo declarado: reducir la carga que generan las contribuciones de baja calidad.
• No se revela en el anuncio: los umbrales concretos, las reglas de recuento por autor y el comportamiento de los borradores ya abiertos al activar la opción.

Conclusiones prácticas

Los mantenedores de repositorios populares deberían revisar su configuración actual de límites y decidir si les conviene contar los borradores. Si en el proyecto los draft sirven como espacio de trabajo para funciones de larga duración, un límite estricto también afectará a los contribuyentes de buena fe. En ese caso, lo razonable es fijar primero la regla en CONTRIBUTING y explicar cómo trabajar con el límite.

Los contribuyentes deberían cerrar con antelación los preparativos que ya no sean relevantes y no mantener varios borradores en paralelo en un repositorio ajeno. Los equipos que lanzan agentes para abrir PR automáticamente tienen que incorporar los límites a su lógica: cola, reintentos y priorización. De lo contrario, el agente chocará con el tope y perderá resultados en silencio.

El cambio es pequeño y no resuelve el problema de la calidad: el límite restringe el volumen, no el contenido. Pero como una capa más de defensa, junto con las plantillas de PR, las comprobaciones obligatorias y la restricción del círculo de autores, funciona. Conviene contrastar la mecánica exacta del recuento con la documentación de GitHub, ya que el propio anuncio ofrece pocos detalles.