Qué hace el cierre de un issue
Terminaste el trabajo, el bug está corregido y el issue sigue abierto en tu tracker.
O tal vez alguien reportó algo que nunca debió ser un issue.
Ahora enfrentas una decisión pequeña pero real: ¿cerrarlo o eliminarlo por completo?
La respuesta corta: cerrar es casi siempre la mejor opción.
Eliminar borra el registro de forma permanente, y GitHub otorga ese poder a muchas menos personas por una razón.
Esta guía explica qué hace realmente cada opción, quién tiene permiso para hacerlo y cómo decidir en situaciones comunes.
Cerrar marca un issue como resuelto, atendido o ya no planeado.
El issue sigue visible en el repositorio, toda su conversación e historial permanecen intactos, y cualquiera puede encontrarlo mediante búsqueda o por enlace.
Según GitHub Docs: cerrar un issue, puedes cerrar un issue cuando los bugs están corregidos o cuando se actúa sobre los comentarios recibidos.
Cerrar también puede indicar que el trabajo no está planeado.
Además, cerrar es reversible en la práctica.
Un issue cerrado puede reabrirse por personas con los permisos adecuados, así que un error es fácil de corregir.
Eso por sí solo hace que cerrar sea la opción predeterminada de bajo riesgo.
GitHub también te permite elegir un motivo al cerrar.
Junto al botón de cierre puedes seleccionar un motivo como completado o no planeado.
Usar el motivo correcto importa: les dice a los futuros lectores si el trabajo se hizo o se rechazó deliberadamente, que es exactamente el contexto que buscarán.
Quién puede cerrar un issue
Cualquiera puede cerrar un issue que haya abierto él mismo.
Para los issues abiertos por otras personas, las reglas dependen del tipo de repositorio.
En un repositorio propiedad de una cuenta personal, el propietario y los colaboradores pueden cerrar issues.
En un repositorio propiedad de una organización, las personas con permisos de triage o superiores pueden cerrar issues abiertos por otras GitHub Docs.