El 4 de septiembre de 2026, Taylor Otwell desactivó la pestaña Issues en la mayoría de los paquetes de código abierto de Laravel. La consigna para los usuarios es directa: describir el error a un agente de código y abrir una pull request, en lugar de redactar un ticket. El repositorio principal del framework queda fuera, pero la decisión reabre el debate sobre cómo se mantiene un proyecto de código abierto con mucho tráfico.
Qué cambió Taylor Otwell
El cambio afecta a los paquetes first-party del ecosistema, los que orbitan alrededor del framework sin ser su núcleo. En esos repositorios, la pestaña Issues de GitHub ya no acepta nuevos tickets. El repositorio laravel/framework permanece fuera del alcance y sigue recibiendo reportes de la forma habitual.
La justificación cabe en una frase que el mantenedor asume: un error se documenta mejor con un arreglo propuesto que con una descripción a la espera. La carga de clasificación, citada a menudo como la primera causa de agotamiento de los mantenedores, se traslada aguas arriba, hacia quien se topa con el problema.
«Si encuentras un error, descríbelo a un agente de código y abre una PR. Aunque el código no sea perfecto, no pasa nada: el código se puede iterar.»
«Describir el error, abrir una PR»: el flujo esperado
El principio desplaza el punto de entrada de una contribución. Donde un ticket abría una conversación, la pull request se convierte en la unidad de reporte: contiene a la vez la descripción del problema y un primer intento de solución. La calidad inicial de ese arreglo pasa a segundo plano, ya que podrá revisarse después. En la práctica, el recorrido propuesto se apoya en las herramientas de línea de comandos habituales.
# Sin ticket: una rama, un arreglo descrito a un agente, una PR
git checkout -b fix/caso-limite
# el arreglo se genera, se revisa en local y se vuelven a pasar las pruebas
git commit -am "Corrige la gestión de la caché en el caso límite"
# la pull request documenta el error Y propone la solución
gh pr create --fill --base mainSymfony toma el camino inverso
La medida contrasta con parte del ecosistema PHP. Varios proyectos, con Symfony a la cabeza, conservan la apertura de tickets como puerta de entrada y confían la escritura del arreglo a sus equipos o a herramientas internas. Se dibujan dos estrategias opuestas ante la misma constatación: el volumen de reportes supera la capacidad de los mantenedores voluntarios.
| Proyecto | Reportar un error | Escribir el arreglo | Papel de la IA |
|---|---|---|---|
| Paquetes de Laravel | Pull request directa | El contribuidor | Generar la propuesta de arreglo |
| Paquetes de Symfony | Ticket clásico | El equipo del proyecto | Asistir del lado del mantenedor |
| Repositorio laravel/framework | Ticket clásico | El mantenedor | No impuesto |
Qué cambia la medida para la contribución
Para el mantenedor, la ganancia es inmediata: menos tickets que clasificar, un repositorio donde cada entrada llega ya con un diff ejecutable. Para el contribuidor, el esfuerzo exigido aumenta. Reportar un error ya no se reduce a describir un síntoma: hay que producir una rama, un arreglo y, en el mejor de los casos, una prueba. El agente de código rebaja esa barrera sin eliminarla, y el enfoque presupone que la persona dispone de esa herramienta y sabe manejarla.
Punto de atención. Un error que un usuario sabe describir pero no corregir corre el riesgo de no reportarse nunca. El cambio también puede trasladar la carga de la clasificación a la revisión, si una avalancha de pull requests aproximadas sustituye a la de tickets. La trazabilidad de un problema depende entonces de la calidad de la PR que lo sostiene.
Lo que hay que recordar
Laravel cierra los tickets de sus paquetes satélite y convierte la pull request asistida por IA en la nueva puerta de entrada, mientras que Symfony mantiene el ticket y conserva el control del arreglo. El framework principal, por su parte, no se mueve. Dos visiones del mantenimiento del código abierto en la era de los agentes de código conviven ya, y los próximos meses dirán cuál aguanta a escala.
Mantengo unos cuantos repositorios, a una escala muy lejana a la de Laravel, y la fatiga de clasificar tickets la conozco bien. La idea de recibir un diff en lugar de un «no me funciona» tiene algo de seductor. Aun así, me mantengo prudente: en mis propios proyectos, los mejores reportes vienen a menudo de usuarios que saben describir un problema a la perfección sin saber resolverlo. Cerrar esa puerta es apostar a que el agente de código cubrirá la diferencia para todos. La apuesta merece observarse; todavía no la generalizaría a un proyecto cuya comunidad no tiene cultura de contribución. — Simon Janvier
Para profundizar
Taylor disabled GitHub Issues on most Laravel open-source packages (Laravel News)
