Qué es realmente un sub-issue
Todo rastreador de trabajo termina teniendo ese issue.
Tiene cinco peticiones distintas enterradas en la descripción, tres personas comentando sobre temas no relacionados y nadie sabe qué significa “terminado”.
La solución obvia es dividirlo en sub-issues.
Dividir demasiado pronto genera desorden: un issue padre sin cerrar, sub‑issues sin reclamar y carga administrativa que supera la claridad buscada.
Esta guía recorre la decisión.
Aprenderás las señales que indican que una tarea realmente necesita dividirse.
También aprenderás cuándo un solo issue te sirve mejor.
Finalmente, verás cómo estructurar los sub-issues para que te ayuden a seguir el progreso.
Un sub-issue es un issue normal con una relación registrada hacia un issue padre.
En GitHub, puedes agregar sub-issues a un issue para dividir piezas grandes de trabajo en tareas.
Los sub-issues muestran su relación con el issue padre, lo que te permite seguir tu trabajo en toda la plataforma.
El progreso de los issues padres y de los sub-issues también está disponible en los proyectos, donde puedes crear vistas, filtrar y agrupar por issue padre.
Los sub-issues pueden contener a su vez sub-issues, de modo que puedes construir jerarquías que visualicen una pieza completa de trabajo.
GitHub permite hasta 100 sub‑issues por issue padre y ocho niveles de anidamiento, mostrando que la función está pensada para estructuras serias, no solo listas.
El punto clave: la relación es visible y legible por las herramientas.
Eso es lo que separa a los sub-issues de simplemente escribir “parte 1, parte 2” en una descripción.
Como el vínculo existe, las herramientas pueden consolidar el progreso y tú puedes filtrar por él.
Señales de que un issue debería dividirse
Usa estas comprobaciones antes de crear nada.
Si varias se cumplen, dividir probablemente valdrá la pena.
- Metas de cierre distintas. El issue describe trabajo que podría entregarse o revisarse en momentos diferentes. Si una parte puede quedar lista esta semana y otra depende de algo fuera de tu control, pertenecen a issues separados.
- Responsables distintos. Dos personas no pueden “ser responsables” de un mismo issue de forma limpia. Si el diseño, la construcción y el lanzamiento tienen cada uno un responsable natural distinto, los sub-issues hacen explícita la responsabilidad.
- Los comentarios se dispersan. Cuando la discusión sobre un aspecto entierra las novedades de otro, los colaboradores dejan de leer el hilo. Issues separados dan a cada conversación su propio hogar.