Evaluación de errores y curación de problemas

El rastreador de incidencias es importante para la comunicación en el proyecto: ayuda a los desarrolladores a identificar los principales proyectos en los que trabajar, así como a discutir las prioridades. Por esta razón, es importante conservarlo, añadiendo etiquetas a las incidencias y cerrando las incidencias que no son necesarias.

Trabajar en las incidencias (issues) para mejorarlas

La mejora de las incidencias aumenta las posibilidades de que se resuelvan con éxito. Las directrices para presentar buenas incidencias pueden encontrarse aquí. Un tercero puede dar una opinión útil o incluso añadir comentarios sobre la incidencia. Las siguientes acciones suelen ser útiles:

• documentar las incidencias en las que faltan elementos para reproducir el problema, como ejemplos de código

• sugerir un mejor uso del formato del código

• sugerir que se reformulen el título y la descripción para que sean más explícitos en cuanto al problema que hay que resolver

• enlazar con incidencias o discusiones relacionadas mientras se describe brevemente cómo están relacionadas, por ejemplo «Ver también #xyz para un intento similar de esto» o «Ver también #xyz donde ocurrió lo mismo en SomeEstimator» proporciona contexto y ayuda a la discusión.

Discusiones fructíferas

Las discusiones en línea pueden ser más difíciles de lo que parece a primera vista, sobre todo teniendo en cuenta que una persona nueva en el mundo del código abierto puede tener una comprensión muy diferente del proceso que un mantenedor experimentado.

En general, es útil mantenerse positivo y asumir la buena voluntad. El siguiente artículo explora cómo dirigir los debates en línea en el contexto del código abierto.

Trabajar en los PR para ayudar a la revisión

También se fomenta la revisión del código. Los colaboradores y usuarios son bienvenidos a participar en el proceso de revisión siguiendo nuestras directrices de revisión.

Operaciones de triaje para los miembros de los equipos centrales y de triaje

Además de lo anterior, los miembros del equipo central y del equipo de triaje pueden realizar las siguientes tareas importantes:

• Actualizar etiquetas para temas y los PR: ver la lista de las etiquetas disponibles en github.

• Determinar si un PR debe ser reetiquetado como estancado (stalled) o si necesita ayuda (esto suele ser muy importante en el contexto de los sprints, donde el riesgo es crear muchos PR inconclusos)

• Incidencias de triaje:

  • cierra las preguntas de uso e indica amablemente al reportero que utilice Stack Overflow en su lugar.

  • cierra las incidencias duplicadas, después de comprobar que efectivamente son duplicados. Lo ideal es que el remitente original traslade la discusión a la incidencia duplicada más antigua

  • cierra las incidencias que no se pueden replicar, después de dejar tiempo (al menos una semana) para añadir información adicional

Las respuestas guardadas son útiles para ganar tiempo y a la vez ser acogedor y educado a la hora de triar.

Consulta la descripción de github para conocer los roles en la organización.

Incidencias de cierre: una decisión difícil

En caso de duda sobre si una incidencia debe cerrarse o no, lo mejor es tratar de llegar a un consenso con el autor original y, posiblemente, buscar los conocimientos técnicos pertinentes. Sin embargo, cuando la incidencia es una cuestión de uso, o cuando se considera poco clara desde hace muchos años, debe cerrarse.

Un flujo de trabajo típico para el triaje de incidencias

El siguiente flujo de trabajo 1 es una buena manera de abordar el triaje de incidencias:

1. Agradece al reportero que haya abierto una incidencia

   El gestor de incidencias (issue tracker) es la primera interacción de muchas personas con el proyecto scikit-learn, más allá del simple uso de la biblioteca. Como tal, queremos que sea una experiencia acogedora y agradable.

2. ¿Es una pregunta de uso? Si es así, ciérrala con un mensaje de cortesía (aquí tienes un ejemplo).

3. ¿Se proporciona la información necesaria?

   Si falta información crucial (como la versión de scikit-learn utilizada), no dudes en pedirla y etiquetar la incidencia con «Needs info».

4. ¿Se trata de una incidencia duplicada?

   Tenemos muchas incidencias abiertas. Si una nueva incidencia parece ser un duplicado, señala la incidencia original. Si es un claro duplicado, o el consenso es que es redundante, ciérralo. Asegúrate de dar las gracias al reportero y anímale a que intervenga en la incidencia original y, tal vez, a que intente solucionarla.

   Si la nueva incidencia proporciona información relevante, como un ejemplo mejor o ligeramente diferente, añádela a la incidencia original como un comentario o una edición al post original.

5. Asegúrate de que el título refleja correctamente la incidencia. Si tienes los permisos necesarios, edítalo tú mismo si no está claro.

6. ¿La incidencia o problema es mínimo y reproducible?

   Para los informes de errores, pedimos que el informante proporcione un ejemplo mínimo reproducible. Mira este útil post de Matthew Rocklin para una buena explicación. Si el ejemplo no es reproducible o si claramente no es mínimo, no dudes en preguntar al reportero si puede proporcionar un ejemplo o simplificar el proporcionado. Reconoce que escribir ejemplos mínimos reproducibles es un trabajo duro. Si el reportero tiene problemas, puedes intentar escribir uno tú mismo.

   Si se proporciona un ejemplo reproducible, pero ves una simplificación, añade tu ejemplo reproducible más sencillo.

7. Añade las etiquetas pertinentes, como «Documentation» cuando la incidencia se refiere a la documentación, «Bug» si se trata claramente de un error, «Enhancement» si se trata de una solicitud de mejora, …

   Si la incidencia está claramente definida y la solución parece relativamente sencilla, etiqueta la incidencia como «Good first issue» (buen primer problema).

   Un paso adicional útil puede ser etiquetar el módulo correspondiente, por ejemplo, sklearn.linear_models cuando sea relevante.

1

Adaptado del proyecto pandas maintainers guide