Los análisis de errores se llevan a cabo en todo el proyecto WordPress como una forma de revisar rápidamente los tickets de Trac e identificar los próximos pasos. Los análisis de errores de rendimiento del núcleoCore El núcleo es el conjunto de software necesario para ejecutar WordPress. El equipo de desarrollo del núcleo crea WordPress. pueden ser organizados por cualquier miembro del equipo en cualquier momento. Dicho esto, el equipo de rendimiento del núcleo organiza un análisis de errores programado cada 2 semanas, los miércoles , y la hora actual de la reunión siempre está actualizada en el calendario de reuniones.
Los análisis de errores son reuniones informales y no requieren publicar una agenda antes ni un resumen después.
Responsabilidades y acceso
Cualquiera puede organizar un análisis de errores. Para organizar el análisis de errores programado con regularidad, añade tu nombre de usuario de WordPress.orgWordPress.org El sitio de la comunidad donde los usuarios crean y comparten el código de WordPress. Aquí puedes descargar el código fuente del núcleo, los plugins y los temas de WordPress, y es también el lugar central para las conversaciones y la organización de la comunidad. https://wordpress.org/ en uno de los espacios de reunión disponibles en la hoja de cálculo de organizadores de análisis de errores. Los representantes del equipo de rendimiento del núcleo son responsables de asegurarse de que las próximas reuniones tengan un organizador asignado. Si a una próxima reunión le falta un organizador, deben solicitar voluntarios amablemente en el canal #core-performance.
No hay requisitos técnicos para organizar un análisis de errores, aparte de tener una cuenta de WordPress.org y una cuenta de SlackSlack Slack es una plataforma colaborativa de chat grupal https://slack.com/. La comunidad de WordPress tiene su propio canal de Slack en https://make.wordpress.org/chat/ de WordPress. Lo ideal es que tengas acceso para usar el comando /here en el canal #core-performance de Slack, pero no es un requisito.
No dudes en organizar un análisis de errores cuando te resulte conveniente. Los análisis de errores quincenales programados existen únicamente para garantizar una periodicidad regular. Sin embargo, siempre se agradecen y son bienvenidos más análisis de errores.
Realización del análisis de errores
Un análisis de errores del equipo de rendimiento del núcleo no es una reunión en el sentido tradicional. El formato consiste en que el organizador del análisis de errores, una sola persona (que va rotando en cada análisis de errores programado), trabaja con un ticket específico de TracTrac Trac es el lugar donde los colaboradores crean incidencias para errores o solicitudes de funcionalidades, de forma similar a GitHub.https://core.trac.wordpress.org/. del núcleo de WordPress o con un «informe» de una incidencia de Performance Lab. Es una reunión informal con una estructura flexible.
Un informe es una lista de tickets específicos de Trac o incidencias de GitHubGitHub GitHub es un sitio web que ofrece una implementación en línea de repositorios git que otros desarrolladores pueden compartir, copiar y modificar fácilmente. Los repositorios públicos son gratuitos; los repositorios privados requieren una suscripción de pago. GitHub introdujo el concepto de «pull request», mediante el cual los cambios de código realizados en ramas por los colaboradores pueden ser revisados y debatidos antes de que el propietario del repositorio los fusione. https://github.com/ que se pueden compartir públicamente con otras personas mediante una URLURL Una dirección web específica de un sitio web o página web en Internet, como la URL de un sitio web www.wordpress.org. Algunos ejemplos:
- Tickets de rendimiento asignados al hito de WordPress 7.0, ordenados por los modificados hace más tiempo
- Tickets de rendimiento con un parche asignados a un hito de una versión futura, ordenados por los modificados más recientemente
- Tickets de rendimiento pendientes de revisión, ordenados por los creados más recientemente
- Tickets de rendimiento pendientes de revisión, ordenados por los modificados hace más tiempo
- Tickets de rendimiento etiquetados como «buen error para empezar», ordenados por los creados más recientemente
- Incidencias de Performance Lab asignadas a hitos de una de las próximas versiones, ordenadas por las creadas más recientemente
- Incidencias de Performance Lab etiquetadas como «buena incidencia para empezar»
- Incidencias de Performance Lab ordenadas por las actualizadas hace más tiempo
El organizador del análisis de errores debe elegir un informe con el que trabajar (de la lista anterior o de cualquier otro informe relevante para el rendimiento) y compartir la URL correspondiente en Slack. Después, debe animar a quienes estén observando a revisar las incidencias relevantes de forma asíncrona y, si es necesario, publicar otro comentario si tienen preguntas o inquietudes sobre una decisión tomada por el organizador del análisis de errores.
Como parte principal del análisis de errores, el organizador debe revisar las incidencias del informe por su cuenta y proporcionar una actualización en cada incidencia que revise. Esto puede consistir en cambiar el hito, cambiar la prioridad, cambiar las asignaciones, cambiar las palabras clave o solicitar una actualización al informador o al autor de la solicitud de incorporación de cambios, por mencionar solo algunos ejemplos.
El organizador del análisis de errores también puede compartir en el canal de Slack cualquier información que considere valiosa. Dicho esto, como el análisis de errores no es una reunión tradicional, no es necesario esperar a que otras personas que puedan estar presentes opinen.
Lo ideal es que cada análisis de errores dure al menos una hora aproximadamente, aunque el organizador es, por supuesto, libre de continuar si lo desea. Cuando deje de revisar incidencias, debe compartir esta actualización en Slack, concluyendo formalmente su análisis de errores.
Mensajes de ejemplo
No dudes en copiar y pegar estos mensajes, o ignorarlos y escribir los tuyos. Estos ejemplos solo sirven como referencia y no constituyen en modo alguno una guía ni es obligatorio utilizarlos.
Inicio del análisis de errores
- /here ¡Hola! Estoy a punto de comenzar un
centrado en el rendimiento. - Hoy revisaré los tickets del siguiente informe: <report-url>
- Dejaré actualizaciones o comentarios en cada ticket a medida que avance por la lista.
- Si estás disponible, no dudes en revisar también estos tickets y compartir cualquier opinión que tengas. Puedes hacerlo respondiendo a la actualización de mi ticket o, si se trata de un ticket al que aún no he llegado, puedes dejar un comentario en el ticket o enviar un mensaje de chat aquí mismo, en el canal.
Fin del análisis de errores
- Y eso es todo por el análisis de errores de hoy. Recuerda que cualquiera puede organizar un análisis de errores como este en cualquier momento. No dudes en contactar si tienes alguna pregunta.
- ¡Gracias a quienes estén por aquí, y nos vemos en 2 semanas!
- </análisis-de-errores>