- Se presentaron públicamente varias mejoras, como sub-issues, tipos de issue y búsqueda de issues.
Administrar los issues con más detalle dividiéndolos en sub-issues
- Con los sub-issues, es posible desglosar y organizar los issues con una estructura jerárquica de padre e hijo.
- Los sub-issues pueden crearse desde cualquier issue, y con una estructura anidada se puede dar seguimiento al progreso e identificar el trabajo restante.
- También es posible seguir fácilmente el avance de los sub-issues dentro de los proyectos.
Organizar el trabajo con tipos de issue
- Con los tipos de issue, se pueden clasificar y administrar los issues con un lenguaje común compartido entre todos los repositorios de una organización.
- Esto permite identificar rápidamente el avance del backlog de bugs, encontrar todas las iniciativas de alto nivel en las que trabaja el equipo y entender cómo se clasifica el trabajo del proyecto.
Encontrar exactamente lo que buscas con búsqueda avanzada
- En la página de issues del repositorio, se puede configurar una búsqueda avanzada usando las palabras clave
AND y OR, así como paréntesis para búsquedas anidadas.
- Se pueden crear filtros más complejos para encontrar exactamente el conjunto de issues que se busca.
Actualización de la interfaz de issues
- Se agregó una nueva barra de filtros en la página índice de issues con autocompletado y resaltado de sintaxis.
- La creación de varios issues ahora es más rápida con la opción 'Create More', que permite volver rápidamente a la pantalla de creación.
- Los formularios y plantillas de issues, que se muestran en orden alfabético según el nombre del archivo, ahora permiten configurarse fácilmente en el orden deseado.
- Con el nuevo botón 'Copy Link', es fácil compartir la URL de un issue.
- En issues largos, al seleccionar 'Load More' ahora se cargan 150 eventos en lugar de 50.
Más capacidad de ítems en GitHub Projects
- Anteriormente se anunció una beta privada para aumentar el límite de ítems por proyecto de 1,200 a 50,000.
- Hoy se amplía el alcance de ese límite incrementado.
- Desde la beta privada, se añadió soporte para slices, swimlanes y la API de GraphQL, además de corregir errores importantes y mejorar el rendimiento.
- Si eres administrador del proyecto y este se acerca al límite de ítems sin usar insights (la única función que aún no es compatible), aparecerá un banner en la parte superior del proyecto.
- Esta actualización se aplica por proyecto, no por organización, por lo que puedes participar haciendo clic en el botón "Join Waitlist" en los proyectos elegibles.
Opinión de GN⁺
- Parece una actualización que lleva las herramientas existentes de seguimiento de issues a otro nivel y que podría mejorar significativamente la colaboración de los equipos de desarrollo de software.
- Aunque usar sub-issues tiene la ventaja de facilitar la descomposición del trabajo y mantener una visión clara del progreso general, una jerarquía demasiado profunda podría perjudicar la legibilidad.
- Resulta especialmente llamativo que la configuración de tipos de issue permita administrar los issues con un lenguaje unificado dentro de la organización. Parece algo que podría mejorar la comunicación y el entendimiento entre equipos.
- La búsqueda avanzada será útil para encontrar rápidamente la información deseada entre grandes volúmenes de issues. Sin embargo, primero hará falta capacitar a los usuarios para que puedan escribir consultas complejas.
- El aumento del límite de ítems en proyectos promete ser de gran ayuda para la gestión de proyectos a gran escala. Aun así, no necesariamente es recomendable concentrar demasiados ítems en un solo proyecto.
1 comentarios
Opiniones de Hacker News
La mayor debilidad de GitHub Issues es que, al visitar la página de un issue, el reporte original se muestra como contenido principal
Quería usar GitHub Issues, pero me decepciona que se haya vuelto más complejo
Si Issues estuviera limitado a los mantenedores del repositorio, sería más fácil contribuir a proyectos FLOSS
Construí la última gran actualización de GitHub Issues hace 10 años y esperaba más
Hace falta agregar estados como "closed - duplicate", "closed - won’t fix", "our bot closed this because no one commented on it for 6 weeks"
No entiendo la reacción negativa
Ya existen las etiquetas, así que no entiendo cuál es el sentido de los tipos de issue
Si agregas varios problemas en los comentarios de un issue, se vuelve difícil hacerles seguimiento
[ ], pero no queda claro quién completó quéEl mayor problema de GitHub Issues es que los grandes proyectos de código abierto no pueden señalar fácilmente los issues prioritarios
Me gustó la renovación de la lista de tareas que usé en el pasado