Qué hace realmente convertir un issue en una discussion
Alguien abre un issue en tu repositorio con una idea poco definida.
No hay ningún bug que corregir ni una tarea clara que completar, pero la conversación podría ser valiosa.
GitHub te permite convertir un issue en una discussion con unos pocos clics.
La plataforma documenta esta función como una herramienta de moderación para ideas que aún están en desarrollo temprano.
Respuesta corta: conviértelo cuando el hilo sea una conversación abierta sin resultado cerrable, y mantenlo como issue si describe un trabajo terminable.
El resto de esta guía muestra cómo tomar esa decisión con confianza.
Según la documentación de moderación de GitHub, cuando conviertes un issue en una discussion, la discussion se crea automáticamente usando el contenido del issue.
Eliges una categoría durante la conversión, confirmas la acción y la conversación sale de tu gestor de issues.
La mecánica es sencilla.
Abre el issue, busca la opción Convert to discussion en el margen derecho, elige una categoría del menú desplegable y confirma.
Las personas con acceso de triage a un repositorio pueden moderar sus discussions, lo que incluye convertir issues de esta manera.
Lo que ganas es un tipo de espacio diferente.
GitHub describe Discussions como un foro abierto para la conversación entre mantenedores y la comunidad.
Los issues, en cambio, están construidos en torno a un trabajo que se puede cerrar: un bug corregido, una funcionalidad lanzada, una pregunta resuelta.
Convertir mueve el hilo de una lista de tareas a un foro.
Cuándo la conversión es la decisión correcta
La señal más clara es que el elemento no tiene línea de meta.
Si no puedes imaginar escribir cerrado como completado en el hilo, probablemente pertenece a una discussion.
La propia guía de GitHub presenta la conversión como la herramienta para ideas que aún están en desarrollo temprano, antes de que se hayan consolidado en una propuesta concreta.
Usa estas comprobaciones al hacer la triage:
- Sin resultado accionable. El hilo es una lluvia de ideas, una recopilación de comentarios o una pregunta abierta para la comunidad, no una tarea definida.
- Múltiples direcciones válidas. La conversación explora opciones, no converge en una única corrección que un pull request podría entregar.
- La participación de la comunidad es el objetivo. Quieres una participación amplia, no una decisión del mantenedor registrada en un gestor.