¿Qué hacer con los problemas abandonados en GitHub?

Si alguien abre un problema en GitHub pero se solicita más información para reproducir el error y nunca se da, ¿cuál es el procedimiento normal? Ejemplo .

Aquí el autor afirma que el "navegador se rompe". Si bien creo que está solucionado, me gustaría recibir noticias del autor para asegurarme de que estamos hablando de lo mismo. Pero a veces el reportero del problema simplemente desaparece. ¿Es una buena práctica común establecer una fecha de vencimiento para los problemas abandonados?

Algo así como estas condiciones:

• Se plantea una pregunta sobre el tema para poder depurarlo.
• Han pasado más de 2 a 6 meses desde la última pregunta / comentario sin respuesta del equipo de desarrollo.
• El error no puede reproducirse al momento de cerrarlo (por cualquier motivo, tal vez nunca podrían reproducirse).
• Se emite una advertencia 2 semanas antes de cerrarla.

¿Qué hacen normalmente los proyectos? No pude encontrar nada en Google. Además, ¿cómo documentaría esto? ¿Es suficiente una simple nota en el archivo README.md que detalla los puntos anteriores y un comentario en el tema que explica por qué se está cerrando?

Nota: es diferente de esta pregunta ya que el error aún puede ser relevante (o no), sin embargo, hay falta de información.

Este es un dilema: no se puede cerrar el problema como "solucionado", porque en realidad no se sabe si se solucionó o, al menos, incluso si se solucionó algún problema, en realidad no se sabe si fue el problema el reportero estaba hablando Por otro lado, no desea dejar abierto un problema que podría haberse solucionado, especialmente si nunca podrá cerrarlo porque nunca obtendrá la confirmación.

Por lo tanto, debe cerrarlo, pero probablemente no como "fijo". Puede inventar un motivo de cierre personalizado "quizás arreglado" o "no confirmado" si quiere ser positivo o "reporternished" si no lo hace. También podría simplemente decir "no se pudo reproducir" y esperar a que aparezca el mismo error para un reportero más receptivo.

Sin embargo, no debe gastar recursos en un error para el que nunca sabrá si realmente se solucionó o no.

Su pregunta principal ya fue respondida, pero también preguntó sobre documentar el proceso y eso también necesita respuesta.

La solución que he visto en muchos proyectos no es ponerlo en el archivo README.md del proyecto, sino en una contribución especial README , un archivo README para contribuyentes. Este archivo describe todo lo que desea que las personas que contribuyen a su proyecto sepan, ya sea sobre el código (convenciones de nomenclatura, organización de módulos, etc.) o sobre el proceso (cómo escribir confirmaciones, cómo manejar tickets, etc.). Este archivo puede ser otro .MDarchivo en el proyecto o colocarse en un repositorio completamente diferente (por lo que se puede compartir entre todos sus proyectos). ¡No olvides vincularlo desde la página principal README.md!

El punto de separar esa información del archivo README principal es que generalmente solo una fracción del usuario del proyecto contribuye directamente a ella. La mayoría de los usuarios no necesitan aburrirse con esa información, solo necesitan saber qué hace su proyecto y cómo usarlo, y eso es lo que debe contener el archivo README principal. En el caso de su proyecto, la sección de contribución es muy pequeña, por lo que no afecta el archivo README principal, pero si documenta todos los flujos de trabajo que desea que sigan los contribuyentes, ya no encajará tan bien ...

Tenga en cuenta que cualquier usuario puede abrir un error, por lo que si tiene requisitos especiales sobre la apertura del error, debe colocarlo en el archivo README principal (aunque trate de mantenerlo en secreto; a diferencia de los contribuyentes de código, los reporteros de errores probablemente estarán menos dispuestos a hacer grandes esfuerzos) para estudiar y cumplir con sus reglas). Sin embargo, la persona que realmente corrige el error y cierra el ticket (ya sea usted o uno de los contribuyentes que ha confirmado) es un contribuyente directo y se puede esperar que lea el archivo README, por lo que el proceso de cierre de tickets cuando el reportero lo hace No responder debe describirse allí.

Leí esto como más una pregunta sobre las prácticas sobre cómo manejar un error no verificado (usando el rastreador de problemas de github) que cualquier otra cosa.

Para mí, esa es una respuesta bastante sencilla basada en otros rastreadores de problemas que he usado. Github no obliga a nadie a usar ningún flujo de trabajo y esto lo hace muy flexible ... y bastante inútil en su configuración predeterminada.

Mirando el flujo de trabajo predeterminado de Bugzilla obtenemos:

Voy a señalar algo muy importante allí: se resuelve como se solucionó antes de cerrarse después de ser verificado . El flujo de trabajo básico de Github muestra solo los estados rojo (abierto) y verde (cerrado).

Por lo tanto, un enfoque es usar las etiquetas dentro de Github ( las etiquetas de su aplicación ) para intentar mostrar la información adicional. Puede crear un par de etiquetas 'no verificadas' y 'verificadas' para aplicarlas una vez que cierre el problema. Tenga en cuenta que este es solo un enfoque: si busca, puede encontrar docenas de enfoques diferentes para el uso de etiquetas. Aquí, la pregunta ¿Cómo gestionar los problemas de github para (prioridad, etc.)? aborda esto.

Lo ha solucionado, desde el punto de vista del desarrollador ya está hecho. Cierra el problema en Github. Aplique la etiqueta 'sin verificar'. Una vez que alguien familiarizado con el error en la versión anterior dice "sí, esto lo solucionó", puede cambiar la etiqueta a "verificado". Si dicen que no, entonces lo vuelves a abrir.

Tenga en cuenta también que hay otros estados resueltos además de 'fijo'. Hay 'wontfix' (la solución es algo que simplemente no se puede hacer con la estructura actual) y 'worksforme' (el error no se puede reproducir) e 'inválido' (está presentando un error sobre el sistema operativo, no las cosas tipo de aplicación).

Tomaría uno de dos puntos de vista, dependiendo de cuán seguro estaba de que estaba hablando de lo mismo que el reportero original:

1) Dado que el reportero ya no está disponible, considere que el error en cuestión significa lo que sea que haya solucionado. Si ayuda, adjunte casos de prueba para aclarar qué fallas encontró. Describa en detalle en el informe de errores qué fue lo que solucionó y deje una nota como "Creo que esto es lo que significa 'interrupciones de navegación', por favor, vuelva a abrir o genere un nuevo error si eso no es lo que quiso decir". Marque el error como solucionado.

2) Dado que el reportero ya no está disponible, considere que el error no puede ser (conocido) reproducido, ya que solo la palabra del reportero confirmará que es lo mismo que informaron. Levante un nuevo error para describir lo que arregló, por razones de crédito, mencione que se observó bajo las condiciones descritas por el reportero ausente, tenga en cuenta que ambos pueden ser duplicados, marque el nuevo error solucionado y marque este no válido o no es reproducible con una nota como "No puedo entender lo que quisiste decir con 'interrupciones de navegación', pero he resuelto el problema que encontré. Vuelve a abrir o genera un nuevo error si la navegación aún se rompe, describiéndolo en más detalles de lo que sale mal ".

En cuanto a la escala de tiempo, creo que debería depender del proyecto. Si es muy receptivo y está lidiando con este error unos días después de que se lo haya planteado, entonces las personas deben comprender que no esperará semanas para recibir una respuesta antes de resolver el problema. Por otro lado, si ha estado en su pila de granizados durante meses, puede permanecer abierto durante otro mes o dos sin causarle ningún problema.

Por esta razón, no creo que haya un límite de tiempo en particular que constituya una "buena práctica", o que necesite publicar su política y cumplirla. Ciertamente, no querrá registrar que el periodista no puede ser contactado hasta que haya hecho un esfuerzo para contactarlos. Pero tampoco veo ningún punto en dejar múltiples advertencias contando hasta una fecha límite: o volverán a visitar el error y querrán decir algo, o no lo harán.