A hand holding a WordPress handmade logo with people and a buinding behind.

Post 2: Control de Calidad y Reporte de Discrepancias en Repositorio de WordPress – Caso Social Icons Block #2233

Continuando con las auditorías del programa WP Credits de la línea de Documentation, seleccioné la incidencia #2233: [HelpHub] Overhaul Social icons block, ubicada en el repositorio oficial WordPress/Documentation-Issue-Tracker en GitHub.

La meta en esta asignación era evaluar la vigencia del manual técnico oficial del bloque “Íconos Sociales” (Social Icons), contrastándolo con el comportamiento real de la interfaz del CMS para garantizar que los usuarios globales reciban instrucciones precisas.

Entorno y Hallazgos

Al realizar las pruebas en vivo en mi entorno de laboratorio (apiedra.blog), procedí a insertar y configurar el bloque de íconos sociales. Durante el análisis sistemático de la barra lateral de configuraciones (Inspector de Bloques), identifiqué discrepancias críticas de interfaz (UI Mismatches) respecto a las capturas de pantalla y pasos lógicos detallados en la documentación oficial:

  • Migración de la pestaña Layout: El manual del repositorio indica y muestra que las opciones de alineación y disposición (Layout) se encuentran anidadas dentro de la pestaña de Configuración (ícono de engranaje). Sin embargo, en el entorno real actualizado de WordPress, se ha segregado este flujo introduciendo una tercera pestaña independiente (representada por el ícono de circulo medio rellenado) dedicada exclusivamente al control de diseño.
  • Opciones huérfanas en la guía: La interfaz real del Core despliega configuraciones adicionales de usabilidad y estructuración que fueron completamente omitidas en el borrador oficial sometido a revisión. En la guía oficial hay solo dos opciones en la barra alteral, pero ahora hay tres, el primero siendo tres lineas horizontales (la cual no esta en la guía), la del engranaje y la de control de diseño.

Al no cumplir con los criterios de aceptación debido a la desactualización del manual por cambios en el Core del CMS, procedí con el protocolo correspondiente al Escenario de Rechazo / Reporte de Ajustes.

En lugar de emitir la frase estándar de aprobación, redacté un reporte de bug técnico formal en inglés dentro del hilo de la incidencia en GitHub, notificando directamente a la coordinadora de documentación sobre la necesidad de actualizar el material gráfico y las instrucciones.

Prubea contribución #2

Leave a Reply

Discover more from WP Documentación & issues tracking

Subscribe now to keep reading and get access to the full archive.

Continue reading