Resumen

  • El Proceso del W3C obliga a atender de forma adecuada y oportuna las consecuencias ya producidas por una decisión revocada; los aspectos estimados de la objeción no están plenamente resueltos hasta entonces. La norma no identifica el registro público que acredita ese cambio de estado.
  • Vibration API aporta un caso con actuaciones reales y verificables, incluido un informe de implementación finalmente completado. También obliga al lector a reconstruir el seguimiento entre informes, issues, pull requests y la revisión de una carta.
  • Un registro de custodia de mitigaciones del Consejo debería separar la recomendación no vinculante de la solución adoptada por la autoridad competente y conectar cada aspecto estimado con acción, fundamento, calendario, evidencia y cierre fechado.

El Consejo termina de decidir antes de que termine el problema

El Consejo del W3C aparece cuando una objeción formal ha resistido los intentos ordinarios de acuerdo. Su decisión es binaria: confirma o revoca el acto impugnado. Los argumentos que justifican la revocación se consideran aspectos estimados de la objeción.

La consecuencia institucional, sin embargo, no siempre es binaria. Una decisión puede haber dejado texto publicado, alterado el estado de una especificación, organizado una carta o activado una dependencia. Revocar la autoridad del acto no deshace esos efectos por sí solo.

Por eso el Proceso añade un segundo momento. El Consejo debe sugerir cómo mitigar las consecuencias relacionadas con los aspectos estimados. El Equipo debe asegurarse de que se apliquen mitigaciones adecuadas y oportunas. Hasta que esto ocurra, esos aspectos no se consideran plenamente resueltos.

La norma crea así un estado posterior al fallo: la decisión ha caído, pero el expediente no ha terminado. Lo sorprendente es que no cree a la vez un soporte público obligatorio para ese estado.

La nota que acompaña a la regla contiene una salvaguarda decisiva. El Equipo no recibe facultades nuevas ni puede, por ejemplo, borrar una publicación. Su tarea consiste en conseguir que quienes sí tienen la autoridad ordinaria actúen con los medios que ya poseen. El grupo conserva el consenso técnico; un presidente conserva sus funciones; el Equipo conserva las suyas. El Consejo no pasa a dirigir el trabajo cotidiano.

Ese reparto evita una concentración de poder, pero abre una brecha de custodia. Quien identifica el defecto no ejecuta necesariamente el remedio. Quien vigila el seguimiento no decide necesariamente el contenido. Si no existe un expediente común, todos pueden actuar de buena fe y aun así dejar incierto qué quedó cerrado.

La suficiencia no puede demostrarse con actividad

“Adecuada” no significa simplemente que hubo movimiento. Una corrección puede mejorar la situación y no responder a todos los argumentos que el Consejo estimó. La prueba razonable exige una matriz entre aspecto, consecuencia, medida y evidencia.

“Oportuna” tampoco equivale a una fecha única para todos los casos. Una modificación administrativa y una solución técnica compleja requieren ritmos distintos. Pero la flexibilidad puede convivir con una fecha objetivo, un punto de revisión y una explicación de los retrasos.

“Plenamente resuelto” es un estado de cierre. El texto no nombra a la autoridad que lo declara, el lugar donde lo publica, la forma de notificar al objetor o la manera de corregir una declaración posterior. Sin esos elementos, la frase tiene fuerza normativa pero carece de recibo operativo.

Vibration API convierte la abstracción en un recorrido comprobable

La revisión del Comité Asesor de finales de 2024 planteó declarar obsoleta la Recomendación Vibration API (Second Edition). Hubo dos objeciones formales. El Grupo de Trabajo de Dispositivos y Sensores decidió en TPAC 2024 hacer retroceder el documento y continuar el trabajo mediante un nuevo Candidate Recommendation Snapshot. Una objeción se resolvió; la otra llegó a un Consejo.

El 10 de agosto de 2025, el Consejo estimó la objeción restante. Su informe describió una situación que ya había cambiado durante la tramitación. El documento era entonces un Candidate Recommendation Draft y, según la regla citada, no podía declararse obsoleto. El Grupo ya lo había hecho retroceder para seguir trabajando y responder a las preocupaciones.

El Consejo recomendó continuar el proceso de publicación, documentar la experiencia de implementación en el issue 33 y presentar, en la siguiente renovación de la carta, un plan concreto y una justificación convincente. No exigió que ese plan tuviera un resultado técnico predeterminado ni que incluyera necesariamente varios grandes motores.

Después hubo acciones tangibles. El issue 33 terminó cerrado como completado el 1 de mayo de 2026. El proceso de la carta de 2026 vinculó la recomendación del Consejo. El issue 781 reclamó el plan público y dio seguimiento al informe. Una pull request posterior propuso planes expresos para especificaciones con un solo motor, incluida una transición de estado si no aparecía una segunda implementación. Cerró sin fusionarse. La revisión más amplia de la carta continuó con otros cambios y con examen del Comité Asesor.

Este recorrido impide afirmar que nadie actuó. También impide saber, desde un solo lugar, qué acto produjo el cierre institucional.

¿La regresión previa era ya una mitigación suficiente o una contención provisional? ¿Cerrar el issue 33 cumplió uno de los aspectos estimados o aportó material para otro juicio? ¿La recomendación sobre el plan quedó satisfecha en otro texto, fue reemplazada por una alternativa consensuada o siguió pendiente? ¿Quién estaba autorizado para decirlo?

El informe del Consejo prueba la decisión. El informe del Equipo explica los antecedentes. El issue técnico prueba una tarea. El issue de carta prueba una exigencia formulada durante la revisión. Las pull requests prueban propuestas. El expediente estratégico prueba la evolución de la carta. Ninguno está designado como registro maestro del estado “plenamente resuelto”.

Por eso hay que evitar atajos. Un issue abierto no demuestra incumplimiento. Un issue cerrado no demuestra cierre del Proceso. Una pull request fusionada demostraría un cambio documental, no necesariamente una mitigación adecuada. El dato ausente es la unión autorizada entre todas esas piezas.

El desacuerdo público ya explica qué no debe hacerse

El issue 751 del repositorio del Proceso permanece abierto desde 2023. Allí se discutió si las recomendaciones del Consejo eran obligatorias, si podían alterar otros consensos y si la regla daba al Equipo un poder demasiado amplio.

Las respuestas establecieron una frontera que este análisis conserva. Las sugerencias del Consejo no obligan a adoptar una solución concreta. Cuando la decisión impugnada ya produjo consecuencias, sin embargo, no es aceptable dejarlas intactas indefinidamente. Deben deshacerse, neutralizarse o mitigarse, y el Equipo debe impedir que la obligación se olvide.

El responsable sustantivo conserva el control. Un Grupo de Trabajo puede desarrollar por consenso una solución distinta de la sugerida. El Equipo no redacta la especificación. Puede, dentro de facultades existentes, requerir atención, actuar sobre la designación de presidencias, frenar una publicación que no cumpla las condiciones de transición o usar mecanismos ya definidos de regresión o abandono.

La discusión reveló, no obstante, una dificultad de lectura. Algunos participantes querían ver expresamente al autor de la decisión original reconsiderando el asunto. Otro resumió el texto como un envío al Equipo tras el cual “ocurre magia”. Quienes defendían la redacción respondieron que la sustancia ya era correcta y que la generalidad era necesaria. La cuestión quedó como mejora editorial aplazada.

La observación más práctica fue que el objetor no debería tener que seguir durante meses o años la resolución de su objeción. No hace falta darle control del remedio para evitarlo. Hace falta que la institución asuma la carga de publicar el estado.

Flexibilidad no significa opacidad

La defensa del modelo vigente merece consideración. Las objeciones pueden recaer sobre decisiones de un grupo, una presidencia, el Equipo, el TAG, el AB o una autoridad de carta. Una regla que siempre asignara el remedio al Grupo de Trabajo sería incorrecta.

Además, el Consejo no debe convertirse en comité técnico superior. Su sugerencia puede ser una vía, pero el responsable ordinario puede encontrar otra respuesta más sólida. La documentación pública del W3C ya es considerable, y la confidencialidad protege deliberaciones, datos reservados a miembros, votos individuales, medidas de personal y asesoría jurídica.

Estas razones justifican un formato ligero y adaptable. No justifican que el cierre sea una inferencia. El registro propuesto no necesita revelar lo protegido ni imponer el contenido de la solución; solo debe hacer visible qué autoridad hizo qué y con qué prueba.

Un registro de custodia desde el informe hasta el cierre

Cuando el Consejo revoque una decisión con efectos existentes, su informe debería abrir un registro versionado de custodia de mitigaciones. El Equipo lo mantendría porque el Proceso le encomienda el seguimiento. Cada responsable añadiría su decisión y evidencia porque conserva la autoridad sustantiva.

El registro debería incluir:

  • informe, fecha y versión del Proceso aplicable;
  • decisión revocada y aspectos estimados;
  • consecuencias ya producidas y artefactos afectados;
  • responsable institucional de cada medida;
  • facultad ordinaria que autoriza su actuación;
  • sugerencia del Consejo marcada como no vinculante;
  • solución aceptada, modificada o alternativa;
  • dependencias, objetivo temporal o siguiente revisión, estado y motivo de demora;
  • publicación, avance o carta condicionados por la mitigación;
  • criterio de aceptación que relacione cada prueba con cada aspecto;
  • estado de notificación o consulta del objetor y del decisor original;
  • autoridad que puede considerar adecuada la medida;
  • declaración fechada de plena resolución, o indicación expresa de que aún no existe;
  • correcciones, sustituciones, recursos y decisiones posteriores;
  • frontera de confidencialidad y justificación de los campos restringidos.

El registro podría documentar que el grupo rechazó la ruta sugerida y adoptó otra mejor. Eso no debilita al Consejo: demuestra que el problema estimado recibió una respuesta dentro de la autoridad correcta. Tampoco crearía un recurso nuevo; una nueva decisión seguiría la vía normal de objeción. Y el Equipo no ganaría poder, porque cada actuación tendría que citar una facultad ya existente.

El cambio fundamental sería distinguir avance de cierre. Abrir un issue, celebrar una reunión o proponer una modificación son señales de trabajo. Solo una prueba comparada con el aspecto estimado permite decir que la mitigación es adecuada.

Límites de la evidencia

Las fuentes públicas no demuestran que el W3C incumpliera un plazo interno, que la respuesta de Vibration siga siendo insuficiente o que algún participante eludiera la decisión. La terminación del issue 33 y la apertura del 781 son hechos distintos, ninguno de los cuales decide por sí solo el estado del Proceso.

El cierre sin fusión de la pull request 809 tampoco prueba rechazo sustantivo ni ausencia de otro plan. Las controversias posteriores sobre la carta de 2026 abarcaron más asuntos que Vibration y no deben emplearse como acusación retroactiva.

La conclusión es institucional: el W3C define un estado que continúa después del fallo del Consejo, pero no exige un documento público que lo lleve hasta su final.

Fuentes

  1. Proceso del W3C de 18 de agosto de 2025 — mitigación
  2. Borrador editorial vigente del Proceso — mitigación
  3. Issue 751 — efectos secundarios de decisiones del Consejo
  4. Guía del W3C — Objeciones formales y Consejo
  5. Informe del Consejo sobre Vibration API, segunda ronda
  6. Informe del Equipo sobre la objeción de Vibration API
  7. Vibration issue 33 — actualizar el informe de implementación
  8. Charter issue 781 — plan recomendado por el Consejo
  9. Strategy issue 530 — carta 2026 de Devices and Sensors
  10. Pull request 809 — planes por especificación
  11. Guide issue 173 — quiénes son los decisores
  12. Process issue 1029 — cuándo publicar un informe del Consejo
  13. Heng Lu — The Multi-Stakeholder Mirage
  14. Heng Lu — On the Agency Problem at the Core of Internet Governance