Resumen
- El 10 de agosto, el W3C Team inició el refinement de una carta para el Immersive Web Working Group. La discusión pública se dirigió al issue 564, mientras que los Miembros también pueden usar la lista confidencial
w3c-ac-forum. - La sección 4.2 del W3C Process obliga a tratar formalmente todos los issues presentados contra el borrador y a seguir su resolución en un disposition of comments que destaque lo no resuelto por consenso.
- El hilo público deja ver varias fases: un comentario de seguridad identificado como bloqueante, una respuesta y la PR 862; preguntas de APA, respuestas y la PR 865. Al cierre del 30 de agosto, ambas PR seguían abiertas y sin fusionar.
- La confidencialidad no debe romperse. Las secciones 7.2 y 7.3 protegen la información Member-only y permiten que la autoridad competente prepare una versión pública no atribuida que comunique lo necesario sin desvelar el material de origen.
- Un registro común puede enumerar clase de problema, versión y sección afectadas, respuesta, diff público o razón para no cambiar, estado de consenso, siguiente paso de autoridad y sucesión. No necesita nombres, texto privado, cifras de participantes ni detalles identificables.
- Participar aporta evidencia y conocimiento; no equivale a un voto del Advisory Committee ni a un mandato popular. Refinement, Team Decision, AC Review y W3C Decision son estados de autoridad distintos.
Dos vías de entrada no deben crear dos historias
El anuncio del 10 de agosto presentó de forma expresa la doble vía. Cualquier persona puede seguir el issue público; los Miembros tienen además un foro reservado. El proceso, sin embargo, conserva un único Chartering Facilitator y una fecha estimada de cierre alrededor del 7 de septiembre.
La asimetría puede mejorar la información. El espacio público permite señalar líneas, proponer cambios y dejar constancia duradera. El espacio protegido puede recibir limitaciones contractuales, planes de implementación no anunciados o evaluaciones cuya atribución perjudicaría relaciones comerciales. Forzar la publicación de todo no garantiza franqueza ni calidad.
Por eso, la existencia de la lista confidencial no demuestra ocultación. Tampoco convierte GitHub en una participación de segunda clase. El problema aparece cuando el lector intenta reconstruir qué ocurrió con las observaciones que podían modificar el mismo instrumento.
No hace falta unir los contenidos. Hace falta unir sus estados. Un mensaje puede seguir siendo reservado y, aun así, el registro público puede indicar que una clase segura de problema afectó una cláusula, recibió una respuesta, provocó una modificación pública o terminó con una razón para no cambiar.
El issue público enseña por qué un solo estado no basta
En la revisión de seguridad, el borrador pedía “secciones” sobre implicaciones de seguridad y privacidad, mientras que la plantilla vigente hablaba de “secciones separadas”. El revisor calificó la observación de bloqueante y fijó una condición concreta. La respuesta reconoció la diferencia y abrió la PR 862. El revisor declaró que consideraría resuelto el bloqueo cuando se fusionara.
Hay una secuencia verificable: problema, respuesta, cambio propuesto y condición de cierre. Al 30 de agosto la PR continuaba abierta. Decir “resuelto” adelantaría un estado; decir “ignorado” borraría la respuesta y el patch.
Las preguntas de APA no siguieron la misma forma. Incluyeron el solapamiento entre plane y mesh detection, el calendario WebGPU y la continuidad de WebGL, y la posición de CSS Spatial Layout y haptics. Las respuestas aclararon límites y generaron la PR 865. APA dijo después que sus preguntas iniciales habían sido respondidas, pero añadió otra sobre la consistencia entre “detection”, “tracking” y “sensing”.
Un sello global de “aprobado” o “objetado” perdería la realidad. Algunas preguntas quedaron contestadas, un cambio seguía sin fusionarse y un asunto terminológico permanecía vivo. La unidad correcta es la cuestión o clase de cuestión, no el interruptor del issue principal.
El número visible de catorce comentarios tampoco mide legitimidad. Un comentario puede contener varias preguntas; varias personas pueden elaborar una sola. Silencio no distingue acuerdo, abstención, desconocimiento o ausencia de autoridad. La actividad no es un plebiscito.
La obligación es disponer los problemas, no exhibirlos
El W3C Process establece la cadena. La Team publica el borrador, indica cómo intervenir, anuncia un periodo no menor de veintiocho días y nombra al facilitador. Durante el refinement se completa la wide review. El Chartering Facilitator busca consenso entre quienes participan; si no lo encuentra, puede pedir una Team Decision y debe documentarse la razón.
La regla central exige que todos los issues contra el borrador sean tratados formalmente y que sus resoluciones se sigan en un disposition of comments, señalando los no resueltos por consenso.
No basta, por tanto, un enlace a una conversación. Debe existir una conexión entre entrada, respuesta y estado. Pero la regla no dice que todo el material recibido se vuelva público. Los niveles de confidencialidad siguen vigentes.
Antes de terminar el periodo anunciado, la Team debe iniciar el AC Review, abandonar la propuesta o extender el refinement. La decisión se anuncia con la visibilidad requerida y, si no se inicia el AC Review, con una razón.
El AC Review posterior usa otra mecánica: una review por organización miembro a través de su representante y Formal Objection para expresar dissent. Un comentario público durante el refinement no es esa review. Una comunicación Member-only tampoco se convierte automáticamente en una objeción formal futura.
Una síntesis pública puede respetar la reserva
La sección 7.2 distingue información pública, Member-only y Team-only. Quien recibe material restringido debe preservarlo y no difundirlo fuera del nivel autorizado. Copiar un correo, nombrar al autor o describir un producto que permita reconocerlo incumpliría la frontera.
La sección 7.3, sin embargo, reconoce que en procesos con una dimensión pública importante puede ser necesario hacer visible información relevante para la decisión. Solo la Team o una parte autorizada puede cambiar el nivel. Si el autor no facilitó una versión apta, la Team puede publicar una versión no atribuida que comunique razonablemente lo requerido y mantenga la reserva original.
Una ficha podría decir: “Clase Member-only M-03: límite de alcance de un deliverable”, señalar sección y commit, registrar si hubo un cambio público y consignar la disposición. No diría quién habló, cuántos Miembros lo hicieron, qué empresa o producto estaba implicado ni reproduciría una frase privada.
Si incluso la clase permite identificar a alguien, debe reducirse la descripción al mínimo estado de proceso publicable. Agrupar datos no elimina por sí solo el riesgo de reidentificación.
Las fuentes revisadas tampoco permiten asegurar que exista una observación confidencial sobre esta carta. Que un canal esté disponible no demuestra que se usó. El registro común no debe llenar esa parte con supuestos.
La participación importa sin convertirse en soberanía
El Process exige considerar las opiniones y objeciones legítimas, procedan de participantes activos o de terceros, incluido el público. Una revisión de accesibilidad, seguridad, privacidad, internacionalización o arquitectura puede descubrir un defecto real. Un implementador puede mostrar que un calendario no encaja con el trabajo técnico.
Eso no convierte a cada comentarista en principal político. El peso de la aportación viene de su evidencia, sus razones y el efecto señalado, no de la etiqueta amplia de stakeholder.
Durante el refinement, el Facilitator busca y valora el consenso de quienes participan. La Team tiene decisiones asignadas y elige el siguiente estado. El Advisory Committee conduce después su revisión formal. Finalmente se produce una W3C Decision.
El registro debe mostrar tanto la aportación, cuando pueda divulgarse, como el rol que respondió y la autoridad que cerró el estado. Así evita dos errores: tratar la revisión pública como teatro porque no es voto, o presentarla como un mandato sin límites.
El esquema mínimo de resolución
La capa común debe ser un índice, no otro archivo de debate. Para cada issue o clase segura debería incluir:
- identificador estable;
- clase de canal, pública o Member-only, sin identidad ni recuento restringido;
- formulación pública segura;
- sección y commit exactos del borrador examinado;
- rol y fecha de respuesta;
- PR, diff, texto alternativo o razón de no cambio;
- disposición: aceptado, parcial, sin cambio, sustituido, retirado, diferido o no resuelto;
- estado de consenso exigido por el Process;
- siguiente autoridad: más refinement, Team Decision, AC Review, extensión o abandono;
- fecha de cierre, evento sucesor e historial de correcciones.
La clase de canal no concede peso. Member-only no significa superior a una revisión técnica pública, y público no significa representativo. El canal informa sobre custodia; la razón y el procedimiento sostienen la decisión.
La referencia de versión es decisiva. Una PR abierta no es texto fusionado y el texto fusionado no es una carta aprobada. La condición de seguridad se cumple únicamente si el cambio alcanza la versión que avanza.
Límites del hallazgo
Al corte, el issue 564 y las dos PR seguían abiertos; el documento era un draft. La página del grupo mostraba que la carta activa continuaba hasta el 25 de septiembre.
Estos estados no demuestran incumplimiento, retraso indebido ni debilidad técnica. El refinement existe para trabajar con comentarios y cambios pendientes. El 7 de septiembre era aproximado y el Process permite anunciar una prórroga.
El enlace de directorio a privacy es solo contextual. No identifica a W3C, al Immersive Web Working Group ni a WebXR y no implica respaldo.
La propuesta es limitada: mantener ambas vías, respetar sus reglas y publicar el mínimo estado que permita inspeccionar la genealogía de una carta.
Fuentes
- W3C — Inicio del refinement de la carta Immersive Web, 10 de agosto de 2026
- W3C — Borrador de carta del Immersive Web Working Group
- w3c/strategy issue 564 — Immersive Web WG 2026 Group Charter
- w3c/charter-drafts PR 831 — borrador inicial de 2026
- w3c/charter-drafts PR 862 — ajuste del texto de coordinación
- w3c/charter-drafts PR 865 — ajuste de descripciones de especificaciones
- W3C Process Document, 18 de agosto de 2025
- W3C — Immersive Web Working Group
- W3C — Carta activa de septiembre de 2024
- w3c/charter-drafts — historial de commits del borrador 2026
- w3c/charter-drafts commit
488587ec141b— marca DRAFT - W3C — Horizontal Review
- Heng Lu — On the Multi-Stakeholder Mirage
- Heng Lu — On the Reality Layers of Internet Governance
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance