- En el repositorio de Ghostty, los usuarios no pueden crear Issues directamente y primero deben iniciar la discusión en GitHub Discussions
- El proyecto no usa el rastreador de Issues para debatir bugs o solicitudes de funciones, y todas las conversaciones se llevan a cabo en Discussions
- Cuando una discusión está lo suficientemente definida como para convertirse en un elemento accionable, un mantenedor la convierte en un Issue
- Este método es una estructura que ayuda a mantenedores y contribuidores a encontrar rápidamente Issues sobre los que realmente se puede trabajar
- Como la mayoría de los reportes son problemas del entorno del usuario, malentendidos o solicitudes de funciones no implementadas, este procedimiento es importante para el control de calidad del proyecto
Política de restricción para crear Issues
- En el repositorio de Ghostty, los usuarios no pueden crear Issues directamente
- En su lugar, primero deben compartir el problema o la propuesta en GitHub Discussions
- Si un mantenedor revisa la discusión y confirma que se trata de un problema claramente reproducible, la convierte en un Issue
- Este método es una estructura para mantener el rastreador de Issues con solo elementos sobre los que realmente se puede trabajar
- Como todos los Issues ya están definidos con suficiente detalle, los contribuidores pueden comenzar a trabajar de inmediato
Principios de operación del rastreador de Issues
- Ghostty no usa el rastreador de Issues para discusiones ni para solicitudes de funciones
- Las solicitudes de funciones y las preguntas generales se manejan en Discussions
- Los Issues solo incluyen bugs claramente definidos o tareas accionables
- Este enfoque es un principio operativo formado a partir de la experiencia manteniendo proyectos de código abierto
- Según la experiencia previa, el 80~90% de los reportes de usuarios no eran bugs reales, sino malentendidos o problemas del entorno
- La mayor parte del resto eran solicitudes de funciones no implementadas, que a menudo requerían especificaciones adicionales
Mejora de la eficiencia de mantenimiento
- Al pasar por la etapa de Discussions, los mantenedores pueden gestionar como Issues solo los problemas validados
- Se reducen los reportes duplicados innecesarios y los reportes de bugs incorrectos
- La lista de Issues queda organizada en torno a elementos sobre los que se puede trabajar de inmediato
- Incluso si un usuario encuentra un problema válido, no necesita hacer trabajo adicional
- Un mantenedor lo convierte directamente en un Issue y lo procesa
Documentación de referencia
- El procedimiento detallado y las pautas de contribución pueden consultarse en el archivo CONTRIBUTING.md
- Ese documento especifica cómo participar en Discussions y los criterios para convertir una discusión en Issue
3 comentarios
Opiniones de Hacker News
Estoy 100% de acuerdo. Si es el proyecto de otra persona, la autoridad para decidir qué cuenta como issue le corresponde por completo a esa persona
Cuanto más grande es el proyecto, más aparecen personas que no leen los mensajes, que hacen pedidos extraños e incluso casos de inflar CVE con IA
Aunque el usuario no entienda qué significa el error, al menos debería decir qué error apareció
Recuerdo que una vez, durante unas pruebas, indiqué explícitamente “broken pipe error”, pero un ingeniero cerró el reporte diciendo “no se puede reproducir” y luego afirmó que no podía reproducirse por ese mismo error
La mayoría de los trackers permiten clasificar con estados como “unconfirmed”, pero GitHub es un sistema de discusión bastante simple, así que es difícil de gestionar
Pasé 4 horas refutándolo con código y evidencias, y la respuesta que volvió fue “shrugs AI”
Con la “Facebookization” se instaló la idea de que todo se resuelve con unos clics, y ahora con la “LLMization” parece que eso se va a agravar aún más
Ese enfoque no encaja con software especializado, pero las expectativas ya se formaron así
Que Ghostty clasifique las solicitudes mediante discusiones es un enfoque poco común, pero válido
La investigación sobre la fuga de memoria está dispersa en varias plataformas
Enlace de X 1, Enlace de X 2, Discusión 1, Discusión 2
Todavía no se elevó a issue oficial
Incluso en un sistema con 8 GB, con solo abrir la terminal unas cuantas veces ya me quedaba sin memoria
Foot tenía menos funciones, pero era mucho más estable
El segundo enlace parece más bien un simple intento de discusión
Analicé el log con Claude Code y lo arreglé de forma temporal, y ahora solo se reproduce 1 de cada 10 veces
Ojalá le sirva a alguien más cuando lo investigue con más detalle
Hay problemas incluso con GPU integradas, pero siempre terminan culpando a GTK o a Nvidia
Me parece que la distinción entre “Issues” y “Discussions” es ineficiente
Hay que buscar duplicados en ambos lados y tampoco se pueden mover tickets
Si das seguimiento por correo, las notificaciones se cortan
Por eso en mi proyecto terminé desactivando Discussions
Si resulta ser un bug real, entonces ahí sí se convierte en issue
Basta con que un administrador ponga la etiqueta “bug”
Cuando la discusión ya esté ordenada, recién ahí se crea el issue
Y las notificaciones se conservan
Algunos proyectos grandes de la comunidad Python también usan este método
Pero desde la perspectiva de un power user, el proceso de reporte de bugs es engorroso
La actitud de “nuestro proyecto es perfecto” puede sentirse arrogante
La mayoría de los reportes de bug de paso no sirven para nada; más bien son ruido
Si de verdad quieres contribuir, es mejor arreglar un bug ya definido
Es totalmente razonable que pongan límites a la forma de reportar
Sobre la idea de que todos los issues deben estar listos para trabajar,
surgió la pregunta: “entonces, ¿no bastaría con poner una etiqueta ‘ready-to-be-worked-on’?”
Este sistema ha sido mucho más exitoso
Por eso separaron el espacio para desarrolladores del espacio para usuarios
Los Issues se vuelven imposibles de manejar cuando crecen demasiado
Usar Discussions como filtro es eficiente
Las dos funciones de GitHub tienen casi la misma UI
Solo que Discussions sí tiene función de upvote
curl/curl/issues
También hay quienes opinan que este método debería ser la configuración predeterminada
Lo ideal sería una estructura donde la comunidad se encargue de las discusiones y los contribuidores de los issues
Con el sistema de etiquetas de GitHub también alcanza
Documentación de gestión de etiquetas de GitHub
Algo como un Natural experiment
Estoy de acuerdo con la política de envíos de usuarios
Si miras las discusiones cerradas, se parecen a los issues cerrados, pero al menos se reduce el ruido en la pestaña de issues
Lista de discusiones cerradas de Ghostty
Muchas discusiones no llegan hasta esa etapa, pero el problema del usuario igual se resuelve
Me parece una arquitectura bastante inteligente
En realidad, eso de que “no se puede abrir un issue” no es una función de GitHub,
sino solo un mensaje de plantilla que dice “no abras un issue nuevo y usa Discussions”
Vi este enfoque en otros proyectos también,
y una estructura que usa las discusiones como punto de partida me parece bastante razonable
Aunque muchos proyectos todavía no han activado GitHub Discussions
¿Cuál sería la diferencia entre esa discusión y un issue? Un issue no es un “bug”. Ya sea un bug, una propuesta de funcionalidad o un PR… si hay algo para debatir, entonces es un issue.
Si no vale la pena discutirlo, se puede cerrar.
No es porque las discussions y los issues sean diferentes, sino simplemente porque probablemente les acomodaba más que estuvieran separados en pestañas distintas.
¿Publicar tanto una especie de lista de tareas como las discussions en la pestaña de issues y administrarlas con etiquetas?
vs
¿Usar la pestaña de issues solo como lista de tareas y las discussions solo como discussions?