¿Cómo gestionar los problemas de github para (prioridad, etc.)? [cerrado]

Soy nuevo en Github y estoy buscando consejos sobre cómo gestionar los problemas. Estoy acostumbrado a tener prioridad y otras opciones de pedido, pero veo que no existen.

¿Cómo gestionan los demás problemas durante el ciclo de vida de un error / función?

Gracias por adelantado.

Se podría definir diferentes grupos de etiquetas como tipos de emisión , las prioridades de emisión , emisión de estados , las etiquetas de versión , y tal vez más. Para poder ver instantáneamente a qué grupo pertenece una etiqueta, puede usar una convención de nomenclatura como <label-group>:<label-name>.

El uso de una convención de nomenclatura de este tipo debería facilitar la gestión de los problemas de Github y ayudar a otros a "comprender" los problemas mucho más rápido. Tenga en cuenta que también puede asignar colores a las etiquetas que pueden agregar aún más a la legibilidad (usaría un color específico para cada grupo de etiquetas). Pero debido a que todavía tiene que asignar / desasignar esas etiquetas a / de los problemas manualmente, es posible que desee mantener pequeña la lista general de grupos / etiquetas.

De acuerdo con el esquema sugerido anteriormente, puede definir grupos y etiquetas correspondientes de la siguiente manera.

grupo 'tipo de problema'

• tipo: error
• tipo: característica
• tipo: idea
• tipo: inválido
• tipo: soporte
• tipo: tarea

grupo 'prioridad de emisión'

• prio: bajo
• prio: normal
• prio: alto

grupo 'estado de problema'

(Estas etiquetas describen el estado de un problema en un flujo de trabajo definido).

• Estado: Confirmado
• estado: diferido
• estado: arreglado
• estado en progreso
• estado: incompleto
• estado: rechazado
• estado: resuelto

grupo 'información de problema'

• información: se necesita retroalimentación
• información: se necesita ayuda
• info: progreso-25
• info: progreso-50
• info: progreso-75

grupo 'etiqueta de versión'

• ver: 1.x
• ver: 1.1

El rastreador de problemas de GitHub es bastante flexible. De hecho, no hay prioridad ni pedidos. Gira en torno a tres pilares principales: Asignaciones , etiquetas e hitos .

• Puede "etiquetar" problemas con las etiquetas que cree (de manera similar a las etiquetas de Gmail). Por ejemplo: "bug", "feature-request", "todo", "question", ... Un problema puede etiquetarse con diferentes etiquetas.

• Puede "agrupar" varios problemas en un hito . Un hito se compone de un título (un número de versión, por ejemplo) y una fecha de entrega opcional.

• Cada problema puede asignarse a un colaborador (colaborador o miembro de la organización) del repositorio. Incluso puede convocar a un colaborador en un comentario usando un @seguido de su inicio de sesión de GitHub.

Finalmente, gracias a la barra lateral, puede "filtrar" la lista de problemas para ayudarlo a administrarla.

Una publicación de blog completa "Issues 2.0" sobre este tema le dará una visión más detallada de las características.

Utilizo huboard.com para representar problemas de github en forma de tablero Kanban, y luego los ordeno arrastrándolos y soltándolos dentro de huboard. Funciona bastante bien si solo le interesa visualizar la prioridad y saber qué trabajar a continuación.

En realidad, almacena la prioridad dentro del problema en sí, como un comentario HTML:

Your normal issue text here...
<!---
@huboard:{"order":465.0}
-->

Ejemplo de cómo usamos etiquetas en github para administrar nuestros proyectos

Etiquetas de categoría (también podría usar todas las mayúsculas para separar visualmente)

• Tarea
• Error
• Característica
• Discusión

Etiqueta de prioridad

• URGENTE

Consideramos que todo tiene prioridad normal y realmente no vemos la necesidad de "bajo". De modo que solo deja una etiqueta para marcar las cosas que necesitan atención inmediata.

Etiquetas de estado

• revisado (el cesionario lo ha leído)
• en cola (el cesionario trabajará pronto)
• trabajo en progreso (el cesionario está trabajando en eso ahora)
• inválido (si el error no es reproducible)
• necesita comentarios (señal de murciélago para que la gente lea y comente o brinde ayuda)

Mantenemos toda la documentación en una wiki que incluye procedimientos, arquitectura, infraestructura, estudios de caso, planificación y requisitos.

Las solicitudes de extracción son para revisiones de código y discusión de características si es parte de una rama

Con un uso creativo del filtrado podemos encontrar cualquier trabajo que necesitemos hacer para el día. "Tarea + URGENTE" o "Error + URGENTE" siempre revisa los problemas etiquetados como "necesita comentarios" y deja un comentario incluso si no tienes nada que agregar. Por supuesto, esto funciona con nuestro equipo de cinco, pero probablemente no mucho más que eso.

Voy por dos tipos de etiquetas en cuestiones de GH: la primera relacionada con el tipo de cuestión y la segunda relacionada con la prioridad:

• error
• característica - (cosas nuevas)
• mejora - (mejorando las cosas existentes)
• pregunta / discusión - (discutiendo cosas)

La pregunta / discusión puede no ser necesaria si usa bien el Wiki. Pero me gusta porque me permite dirigir una pregunta o una idea a una persona en particular.

Luego hay tres etiquetas de prioridad realmente simples:

• ahora
• pronto
• más tarde

Fácil, verdad?

Además de las soluciones de etiquetado sugeridas anteriormente, tenemos blockingy blockedcomo etiquetas.

Primero se debe asignar un problema a la persona correcta, pero si esa persona no puede trabajar en el problema hasta que se haya resuelto algún otro problema, el problema se marca como blocked. Y se hace referencia al otro problema con una etiqueta hash.

Del mismo modo, si una tarea está bloqueando a otra persona para que no trabaje en algo, debe marcarse como blockinguna referencia al otro problema.

Me resultó un poco complicado descubrir cómo enumerar los elementos asignados a una persona en particular;

La solución es hacer clic en el ícono de 'búsqueda' (sin ingresar ningún criterio de búsqueda) y en la página de resultados hay un menú desplegable a la izquierda.