Clasificación de errores y curación de problemas #

El rastreador de problemas es importante para la comunicación en el proyecto porque sirve como la ubicación centralizada para realizar solicitudes de funciones, informar errores, identificar proyectos importantes en los que trabajar y discutir prioridades. Por esta razón, es importante seleccionar la lista de problemas, agregando etiquetas a los problemas y cerrando los problemas que están resueltos o no se pueden resolver.

La clasificación de problemas no requiere ninguna experiencia particular en el interior de Matplotlib, es extremadamente valiosa para el proyecto, ¡e invitamos a cualquiera a participar en la clasificación de problemas! Sin embargo, las personas que no forman parte de la organización de Matplotlib no tienen permisos para cambiar hitos, agregar etiquetas o cerrar incidencias . Si no tiene suficientes permisos de GitHub para hacer algo (por ejemplo, agregar una etiqueta, cerrar un problema), ¡deje un comentario @matplotlib/triageteamcon sus recomendaciones!

Trabajando en temas para mejorarlos #

Mejorar los problemas aumenta las posibilidades de que se resuelvan con éxito. Las pautas para enviar buenos números se pueden encontrar aquí . Un tercero puede brindar comentarios útiles o incluso agregar comentarios sobre el problema. Las siguientes acciones suelen ser útiles:

  • documentar problemas a los que les faltan elementos para reproducir el problema, como ejemplos de código

  • lo que sugiere un mejor uso del formato del código (por ejemplo, tres marcas de retroceso en el descuento).

  • sugiriendo reformular el título y la descripción para hacerlos más explícitos sobre el problema a resolver

  • vincular a problemas o debates relacionados mientras se describe brevemente cómo están relacionados, por ejemplo, "Ver también #xyz para un intento similar en esto" o "Ver también #xyz donde se informó lo mismo" proporciona contexto y ayuda a la discusión

  • verificar que el problema sea reproducible

  • clasifique el problema como una solicitud de función, un error de larga data o una regresión

equipo de triaje #

Si desea unirse al equipo de triaje:

  1. Triage correctamente 2-3 problemas.

  2. Pídele a alguien del equipo de triaje (público o privado) que te recomiende al equipo de triaje. Si trabajó con alguien en el problema evaluado, sería una buena persona para preguntar.

  3. ¡Ejerce responsablemente tu nuevo poder!

Cualquier persona con derechos de confirmación o clasificación también puede nominar a un usuario para que se le invite a unirse al equipo de clasificación.

Operaciones de triaje para miembros de los equipos central y de triaje #

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

  • Actualizar etiquetas para incidencias y relaciones públicas: consulte la lista de etiquetas de github disponibles .

  • Problemas de clasificación:

    • reproduzca el problema , si el código publicado es un error, etiquete el problema con "estado: error confirmado".

    • identificar regresiones , determinar si el error informado solía funcionar como se esperaba en una versión reciente de Matplotlib y, de ser así, determinar la última versión funcional. Las regresiones deben marcar hitos para la próxima versión de corrección de errores y pueden etiquetarse como "Versión crítica".

    • cierre las preguntas de uso y señale cortésmente al reportero que use discurso o desbordamiento de pila en su lugar y etiquételo como "apoyo de la comunidad".

    • cierre los problemas duplicados , después de comprobar que efectivamente están duplicados. Idealmente, el remitente original mueve la discusión al problema duplicado más antiguo.

    • cerrar problemas que no se pueden replicar , después de dejar tiempo (al menos una semana) para agregar información adicional

Un flujo de trabajo típico para la clasificación de problemas #

El siguiente flujo de trabajo [ 1 ] es una buena manera de abordar la clasificación de problemas:

  1. Agradecer al reportero por abrir un problema.

    El rastreador de problemas es la primera interacción de muchas personas con el proyecto Matplotlib en sí, más allá del uso de la biblioteca. Por ello, queremos que sea una experiencia agradable y acogedora.

  2. ¿Es esta una pregunta de uso? Si es así, ciérralo con un mensaje cortés.

  3. ¿Se proporciona la información necesaria?

    Compruebe que el cartel haya rellenado la plantilla de problemas. Si falta información crucial (la versión de Python, la versión de Matplotlib utilizada, el sistema operativo y el backend), pídale cortésmente al autor original que proporcione la información.

  4. ¿Es el problema mínimo y reproducible?

    Para los informes de errores, le pedimos al reportero que proporcione un ejemplo reproducible mínimo. Consulte esta útil publicación de Matthew Rocklin para obtener una buena explicación. Si el ejemplo no es reproducible, o si claramente no es mínimo, no dude en preguntarle al reportero si puede proporcionar un ejemplo o simplificar el proporcionado. Reconozca que escribir ejemplos reproducibles mínimos es un trabajo duro. Si el reportero tiene dificultades, puede intentar escribir uno usted mismo.

    Si se proporciona un ejemplo reproducible, pero ve una simplificación, agregue su ejemplo reproducible más simple.

    Si no puede reproducir el problema, infórmelo junto con las versiones de su sistema operativo, Python y Matplotlib.

    Si necesitamos más información de este paso o del anterior, etiquete el problema con "estado: necesita aclaración".

  5. ¿Es esto una regresión?

    Si bien nos esforzamos por tener una biblioteca libre de errores, las regresiones son la máxima prioridad. Si hemos roto el código de usuario que solía funcionar, ¡deberíamos arreglarlo en la próxima versión del parche!

    Intente determinar cuándo ocurrió la regresión ejecutando el código de reproducción en versiones anteriores de Matplotlib. Esto se puede hacer con las versiones publicadas de Matplotlib (para obtener la versión en la que funcionó por última vez) o usando git bisect para encontrar la primera confirmación donde se rompió.

  6. ¿Es este un problema duplicado?

    Tenemos muchos temas abiertos. Si un problema nuevo parece ser un duplicado, señale el problema original. Si es un duplicado claro, o el consenso es que es redundante, ciérrelo. Asegúrese de seguir agradeciendo al reportero y anímelo a intervenir en el problema original y tal vez a tratar de solucionarlo.

    Si el nuevo problema proporciona información relevante, como un ejemplo mejor o ligeramente diferente, agréguelo al problema original como un comentario o una edición de la publicación original.

    Etiquete el problema cerrado con "estado: duplicado"

  7. Asegúrese de que el título refleje con precisión el problema. Si tiene los permisos necesarios, edítelo usted mismo si no está claro.

  8. Agregue las etiquetas relevantes, como "Documentación" cuando el problema se trata de documentación, "Error" si es claramente un error, "Nueva función" si es una solicitud de nueva función, ...

    Si el problema está claramente definido y la solución parece relativamente sencilla, etiquételo como "Buen primer problema" (y posiblemente una descripción de la solución o una pista sobre dónde buscar en la base del código para comenzar).

    Un paso útil adicional puede ser etiquetar el módulo correspondiente, por ejemplo, la etiqueta "GUI/Qt" cuando sea relevante.

Trabajando en relaciones públicas para ayudar a revisar #

También se recomienda revisar el código. Los colaboradores y usuarios son bienvenidos a participar en el proceso de revisión siguiendo nuestras pautas de revisión .

Agradecimientos #

Esta página está ligeramente adaptada del proyecto scikit-learn .