Seguimiento distribuido de problemas [cerrado]

El seguimiento distribuido de problemas me parece una buena idea, pero en realidad nunca ha despegado a lo grande. ¿Hay una buena razón para eso?

Estoy consciente de:

Bugz en todas partes
- demasiado complejo para configurar
- demasiados requisitos
- razonablemente exitoso, utilizado por algunos proyectos grandes
fósil
- intenta integrar demasiadas cosas, y termina siendo una versión ligeramente peor de todas ellas, excepto quizás por la parte de seguimiento de problemas distribuidos, que es decente (probablemente la mejor que he visto)
varios otros proyectos más pequeños
- ninguno de los cuales ha ganado tracción

Estoy pensando en hacer el mío, pero antes de comenzar, me gustaría saber por qué ninguno de los otros ha despegado a lo grande.

Problemas anticipados: (creo que todos pueden superarse)

fusionar problemas distribuidos a medida que se actualizan es complejo, al igual que fusionar cualquier archivo de código
la continuidad de la conversación puede destruirse, ya que los comentarios pueden aparecer en cualquier momento, tal vez no en el flujo correcto
expectativa del servidor central con problemas actualizados

version-control issue-tracking distributed-computing

— Billy Moon
fuente

Mi 2c es que el seguimiento distribuido de problemas no tiene mucho sentido en muchos sentidos: el objetivo del seguimiento de problemas es mantener a todos en la misma página de manera centralizada, es bueno. Si quisiera distribuirlo, simplemente usaría evernote.

— Wyatt Barnett

@WyattBarnett que es una preocupación válida, tal vez mitigada por patrones de comportamiento, y tal vez software. Personalmente, veo que la única diferencia entre un blog y un sitio web es la frecuencia con la que lo actualizas, ¿no es lo mismo para el seguimiento distribuido de problemas? Si lo actualiza con frecuencia, es lo mismo que revisar una página web de problemas a menudo, ¿no? El único peligro es que las personas no actualicen y envíen problemas con frecuencia, pero siempre que haya una solución de un solo clic, no es un problema, ¿verdad? Entiendo que esta necesidad de conectividad está en conflicto con uno de los grandes beneficios del distributedseguimiento de problemas.

— Billy Moon el

No enviar problemas es el problema número 1 que he visto en los rastreadores de errores. Como @JeffO señala que tener algunas capacidades fuera de línea es mucho más importante que tener un sistema distribuido. De la misma manera, git es bueno, pero github realmente hace que git valga la pena.

— Wyatt Barnett

@WyattBarnett es difícil especular cómo reaccionaría la gente ante una herramienta bien formada. Quizás tendrían más probabilidades de enviar problemas si fuera posible sin conexión y sin conexión / iniciar sesión explícitamente. Quizás las personas que envían problemas en línea terminarían retrasando sus publicaciones si estuviera disponible sin conexión. Mi intuición es que si se hace extremadamente simple empujar, la gente lo hará con frecuencia, porque si han creado un problema, querrán que el mundo lo vea.

— Billy Moon

¿Cómo manejará un gerente dos proyectos diferentes con cierta superposición de miembros del equipo? Ellos van a querer algún tipo de capacidad de informes en toda la empresa.

— JeffO

Respuestas:

Solo porque el control de fuente + distribuido fue un gran éxito, el seguimiento de problemas + distribuido no es necesariamente una buena idea.

¿Qué ganamos con el control de fuente distribuida y se aplicaría al seguimiento de problemas?

Fácil ramificación y fusión : en realidad no. En realidad, es crucial que todos estén en la misma página. Entonces ramificar sería muy indeseable.

Rendimiento : la cantidad de datos transmitidos por un rastreador de problemas es bastante pequeña, y todo el trabajo pesado se realiza en el servidor, por lo que esto no es un problema.

Flujos de trabajo avanzados (push, pull, puesta en escena, etc.): los rastreadores de problemas ya tienen flujos de trabajo buenos (y a menudo altamente configurables). Entonces no necesitamos un sistema distribuido para eso. Todo lo contrario, haría las cosas mucho más difíciles, ya que tienes que lidiar con cambios conflictivos.

Capacidades sin conexión : seguro, estas serían buenas. Sin embargo, estos también se pueden tener sin ir completamente distribuidos.

Además, el control de fuente (distribuido) es utilizado casi exclusivamente por los programadores. El seguimiento de problemas también es utilizado por probadores, diseñadores, escritores técnicos, gerentes, marketing y, a veces, incluso usuarios finales. Estas personas menos sin experiencia en informática podrían tener dificultades para comprender las complejidades de un sistema distribuido.

— oefe
fuente

Me imagino que el seguimiento distribuido de problemas también funciona como servidor, de la misma manera que git. Esperaría que los desarrolladores lo usen, con su configuración local (potencialmente fuera de línea a veces), y que otras personas lo usen solo desde el servidor central. ¿Crees que eso mitiga algunas de tus preocupaciones?

— Billy Moon

No creo que los conflictos de fusión sean un gran problema, ya que cada nueva entrada en un problema irá acompañada de una marca de tiempo, por lo que los conflictos de fusión deberían resolverse fácilmente (automáticamente por el programa) utilizando estas marcas de tiempo. No espero que el contenido existente cambie mucho. ¿Crees que esto es realista?

— Billy Moon

¿Otras personas usan el seguimiento de problemas antes de que haya un repositorio para compartir el código, o antes de que el repositorio se use para rastrear el código?

— Billy Moon

Me imagino que para proyectos pequeños / trabajos de consultoría sería muy útil poder agregar el seguimiento de problemas al proyecto de manera distribuida. Luego se convierte en parte del archivo del proyecto automáticamente, y también hace que sea fácil tener algún tipo de seguimiento de problemas, sin administrarlo como una entidad separada. ¿Ves esto como un beneficio potencial?

— Billy Moon

La estrecha integración con el VCS permitiría que el rastreador de problemas se mantenga actualizado fácilmente. Si codifico algo mientras estoy desconectado, puedo tener actualizado el rastreador de problemas integrado, tal vez cerrando un problema, y luego, cuando me conecto nuevamente, empujo todos los cambios al código y los problemas juntos. ¿Crees que esto es realista / problemático / útil?

— Billy Moon

No creo que ser descentralizado sea tan importante como tener capacidades fuera de línea. La integración con el control de origen es un gran beneficio, por lo que desea que cada usuario pueda manejar convenientemente ambas tareas. Cuanto más juntos lo hagan, más continuidad tendrás.

Incluso los equipos más distribuidos deberían poder armar un servidor web y un sistema de seguimiento. Sería más beneficioso tener un rastreador de errores central ya que cada usuario solo necesita un subconjunto de la base de datos de errores. Los errores generalmente se asignan a alguien que puede trabajar en él individualmente. No hay nada de malo en no estar disponible para todos los demás si utiliza algún tipo de sistema de "salida" que lo deja en un estado de solo lectura. Un sitio web también permite a los clientes / usuarios ingresar y ver sus propios tickets.

Tienes algo con la necesidad fuera de línea, pero muchos de los problemas que abordaste podrían evitarse simplemente revisando partes del rastreador de errores para trabajar mientras estás desconectado.

Para muchos usuarios, una de las mejores herramientas de integración es el correo electrónico, especialmente cuando tienes personas fuera del equipo. No voy a volver a su sitio web para ver si mi problema se ha resuelto. Quiero un correo electrónico con un posible enlace de respuesta para proporcionar comentarios. Cualquier desarrollador que responda a un correo electrónico de solicitud de cambio puede enviar una respuesta y hacer un seguimiento en el sistema.

— JeffO
fuente

Para mí, tiene más sentido incluir los problemas en el proyecto VCS, para que todos los problemas estén disponibles, y es un problema de informes para extraer los relevantes. Creo que los gastos generales en el repositorio son aceptables, ¿qué te parece? En cuanto a un servidor central, imagino un sistema después de git, donde está en su implementación, totalmente distribuido, pero puede alojarlo en un servidor que llama el central (como github, por ejemplo). ¿Alguna idea?

— Billy Moon

Los temas activos son los relevantes. No estoy seguro de qué tan atrás en la historia me gustaría que llegara mi base de datos local de errores. Estoy contigo en el central, similar a Github. Solo pienso en la parte de seguimiento de errores como más de una lista de tareas que está vinculada al código y no una copia de toda la base de datos.

— JeffO

¿Está esa preocupación enraizada en el problema de examinar datos irrelevantes? o desde el punto de vista del espacio de almacenamiento?

— Billy Moon

@BillyMoon: no creo que el almacenamiento sea tan problemático como el tiempo para sincronizar las entradas de seguimiento de todos. Puede que no sea un gran problema, pero todavía lo estoy poniendo en el contexto del seguimiento de llamadas distribuidas en lugar de simplemente hacer una entrada a un sitio web.

— JeffO

Voy a ser muy específico sobre los productos reales. A algunos probablemente les gustará esto y a otros quizás no, pero aquí va:

He utilizado muchas herramientas a lo largo de los años para el seguimiento de problemas, tareas y proyectos. Microsoft Project, Trello y Jira han tenido su lugar.

Ahora uso Pivotal Tracker. Me encanta su sofisticación y su simplicidad de uso, y realmente me gusta la forma en que a medida que otras personas editan y actualizan tickets, esos cambios también se hacen y resaltan en su ventana, por lo que es el mejor estilo de 'red' de estas herramientas que yo ' lo intenté.

No estoy totalmente seguro de si eso es lo que quieres decir con distribuido, pero ahí lo tienes.

Si es así, me acostumbraría y luego vería las deficiencias de Pivotal Tracker (si las hubiera) antes de desarrollar una alternativa.

— Michael Durrant
fuente