¿Qué hacer con los problemas abandonados en GitHub?

Este es un dilema: no puede cerrar el problema como "solucionado", porque en realidad no sabe si se solucionó, o al menos incluso si algunos se solucionó el problema, en realidad no se sabe si este era el problema del que hablaba el periodista. Por otro lado, no desea dejar un problema que se haya solucionado, especialmente si nunca podrá cerrarlo porque nunca obtendrá la confirmación.

Entonces, deberías cerrarlo, pero probablemente no como "arreglado". Podría inventar un motivo de cierre personalizado "tal vez arreglado" o "no confirmado" si quiere ser positivo o "reportero" si no lo hace. También puedes simplemente decir "no se pudo reproducir" y esperar a que aparezca el mismo error para que aparezca un reportero más receptivo.

Sin embargo, no debes gastar recursos en un error por el que nunca sabrás si realmente fue arreglado o no.

Su pregunta principal ya fue respondida, pero usted también preguntó acerca de documentar el proceso y eso también necesita ser respondido.

La solución que he visto en muchos proyectos es no ponerla en el archivo README.md del proyecto, sino en un contribucion README especial: un archivo README para colaboradores. Este archivo describe todo lo que desea que las personas que contribuyen a su proyecto conozcan, 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 archivo .MD en el proyecto, o puede ubicarse en un repositorio completamente diferente (para que pueda ser compartido entre todos sus proyectos). ¡No olvide enlazar desde el README.md principal!

El punto de separar esa información del 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 README principal. En el caso de su proyecto, la sección contribución es muy pequeña, por lo que no grava el README principal, pero si documenta todos los flujos de trabajo que desea que sigan los contribuyentes, ya no se ajustará tan bien allí. .

Tenga en cuenta que cualquier usuario puede abrir un error, por lo que si tiene requisitos especiales sobre la apertura de errores, debe incluirlos en el README principal (aunque intente mantenerlo en secreto), a diferencia de los contribuyentes de código, los informadores de errores probablemente estarán menos dispuestos a hacerlo. a grandes distancias estudiar y ajustarse a 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 README de la contribución, por lo que el proceso de cierre de tickets cuando el reportero lo hace. No responder debe ser descrito allí.

Leí esto como una pregunta más 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.

Al observar el flujo de trabajo predeterminado de Bugzilla obtenemos:

Voyaseñalarunacosamuyimportanteallí:seresuelvecomosearreglóantesdequesecierredespuésdeserverificado.ElflujodetrabajobásicodeGithubmuestrasololosestadosrojo(abierto)yverde(cerrado).

Porlotanto,unenfoqueesusarlasetiquetasdentrodeGithub( etiquetas de su aplicación ) para tratar de mostrar la información adicional. Puede crear un par de etiquetas que están "sin verificar" 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 administrar los problemas de github (prioridad, etc.)? aborda esto.

Lo has arreglado, desde el punto de vista de un desarrollador, está hecho. Cierra el tema en Github. Aplique la etiqueta 'no verificada' a ella. Una vez que alguien familiarizado con el error en la versión anterior dice "sí, esto lo ha solucionado", puede cambiar la etiqueta a 'verificada'. Si dicen que no, entonces lo vuelves a abrir.

Tenga en cuenta también que hay otros estados resueltos además de 'arreglado'. 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 el tipo de aplicación cosas).

Tomaría uno de los dos puntos de vista, dependiendo de cuánta confianza tenía en 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 detalladamente el informe de errores que solucionó y deje una nota como: "Creo que esto es lo que significa 'saltos de navegación', por favor vuelva a abrir o genere un nuevo error si eso no es lo que quería decir". Marque el error como corregido.

2) Dado que el reportero ya no está disponible, considere que el error no se puede reproducir (se sabe que se puede reproducir), ya que solo la palabra del reportero confirmaría que es lo mismo que informaron. Genere un nuevo error para describir lo que solucionó; por motivos de crédito, mencione que se observó en las condiciones descritas por el informante ausente, tenga en cuenta que ambos pueden estar duplicados, marque el nuevo error solucione y marque este como inválido o no reproducible con una nota como, "No puedo entender lo que quiso decir con 'nav breaks', pero resolví el problema que encontré. Vuelva a abrir o genere un nuevo error si la navegación aún se rompe, describiendo con más detalle lo que va 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 a los pocos días de haberse producido, entonces la gente debe entender que no esperará semanas para recibir una respuesta antes de resolver el problema. Por otro lado, si ha estado en tu slushpile durante meses, puede permanecer abierto durante uno o dos meses más sin que te cause 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 atenerse a ella. Ciertamente, no querrá registrar que no se puede contactar al reportero hasta que haya hecho un esfuerzo por contactarlos. Pero tampoco veo ningún punto en el que las advertencias múltiples cuenten hasta una fecha límite: o volverán a revisar el error y querrán decir algo, o no lo harán.