Кратко

  • 10 августа W3C Team начала refinement проекта хартии Immersive Web Working Group. Для публичного обсуждения указан strategy issue 564, а членам разрешено обсуждать проект в конфиденциальном w3c-ac-forum.
  • Раздел 4.2 W3C Process требует формально рассматривать все issues против проекта и отслеживать их разрешение в disposition of comments, отдельно отмечая вопросы, не решенные консенсусом.
  • Публичный поток уже показывает цепочку: блокирующее замечание по безопасности, ответ и PR 862; вопросы APA, ответы и PR 865. На 30 августа оба PR оставались открытыми и не были слиты.
  • Конфиденциальность нужно сохранять. Разделы 7.2–7.3 защищают Member-only сведения и позволяют уполномоченной стороне подготовить неатрибутированную публичную версию, которая сообщает необходимое, не раскрывая исходный материал.
  • Общий реестр должен содержать класс вопроса, затронутую версию и раздел, ответ, публичный diff или мотив отказа от изменения, состояние консенсуса, следующий уровень полномочий и историю замены. Имена, закрытые формулировки и позволяющие идентификацию подсчеты там не нужны.
  • Участие приносит доказательства и экспертизу, но не является голосом Advisory Committee или мандатом неопределенного «общества». Refinement, Team Decision, AC Review и W3C Decision остаются разными состояниями власти.

Разная видимость не означает разную ценность

Уведомление от 10 августа прямо описывает оба пути. Публичный issue открыт для ранней дискуссии; для членов есть защищенный форум. При этом речь идет об одном Chartering Facilitator и об одном периоде refinement, ориентировочно до 7 сентября.

Публичный канал дает проверяемость: точную строку, patch и доступный архив. Закрытый канал может принять неанонсированный план внедрения, договорное ограничение или оценку, чье авторство само по себе создало бы коммерческий риск. Обязательная публикация каждого слова способна уменьшить откровенность, не улучшив решение.

Сам факт закрытого канала не доказывает скрытого управления. Он даже не доказывает, что канал использовали. Одновременно публичный GitHub нельзя считать декорацией только потому, что существует другой вход. Контрольный вопрос возникает после получения замечания: остается ли прослеживаемый путь к тексту?

Объединять нужно не исходные сообщения, а их disposition. Письмо сохраняет свой режим доступа. Публичный слой может зафиксировать безопасный класс проблемы, затронутую норму, институциональный ответ и итог: изменение, обоснованное отсутствие изменения или открытое состояние.

Публичный issue показывает несколько независимых состояний

Рецензент по безопасности заметил различие между словом «sections» в проекте и «separate sections» в действующем шаблоне для описания последствий безопасности и приватности. Он назвал замечание blocking и задал критерий закрытия. В ответ был открыт PR 862. Рецензент подтвердил: блокировка будет снята после merge.

Здесь видны проблема, ответ, предложенный diff и условие закрытия. На дату отсечения PR оставался open. Наличие исправления еще не означает, что текст исправлен; но оно исключает вывод, будто замечание проигнорировано.

APA задала вопросы иной структуры: о пересечении plane и mesh detection, сроках WebGPU и продолжении WebGL, месте CSS Spatial Layout и haptics. Ответы уточнили границы и привели к PR 865. APA сочла исходные вопросы отвеченными, а затем подняла новый вопрос о последовательности терминов «detection», «tracking» и «sensing».

Свести это к «APA согласилась» или «APA возразила» нельзя. Часть вопросов получила ответы, предложенный текст не был слит, терминологическая тема продолжалась. Реестр должен работать на уровне вопроса, а не общего флажка.

Число 14 comments также ничего не говорит о представительстве. В одном комментарии может быть пять вопросов, а несколько людей могут править одну фразу. Молчание не различает согласие, воздержание, неосведомленность и отсутствие полномочий. Активность не равна голосованию.

Process требует связать вопрос с разрешением

Для запуска refinement Team публикует проект, объясняет участие, объявляет срок не менее 28 дней и называет Facilitator. В этот период проходит wide review. Facilitator ищет консенсус среди участников; если его нет, он может запросить Team Decision, чье обоснование должно быть задокументировано.

Ключевое требование гласит: все issues против проекта должны быть формально рассмотрены, а их решения — отслеживаться в disposition of comments с выделением того, что не решено консенсусом.

Ссылки на дискуссию недостаточно. Нужна связь между входом, ответом и статусом. Однако норма не требует публиковать каждую полученную фразу и не отменяет уровни конфиденциальности.

До конца объявленного срока Team должна начать AC Review, отказаться от предложения или продлить refinement. Решение публикуется с требуемой видимостью; если AC Review не начинается, требуется мотивировка.

AC Review — отдельная стадия. Каждая организация-член подает одну review через своего представителя, а dissent выражается как Formal Objection. Комментарий GitHub в ходе refinement не является такой review. Закрытое замечание также не становится автоматически будущим Formal Objection.

Публичный индекс можно построить без раскрытия

Раздел 7.2 различает public, Member-only и Team-only. Допущенные к закрытым данным обязаны сохранять их конфиденциальность. Копирование письма, указание автора или деталей, по которым узнают компанию, нарушило бы саму границу.

Раздел 7.3 одновременно признает: в процессах со значимой публичной частью информация, влияющая на решения, может нуждаться в публикации. Менять уровень может только Team или уполномоченная ею сторона. Если автор не подготовил подходящий вариант, Team вправе опубликовать неатрибутированную версию, разумно передающую необходимое и уважающую исходный режим.

Строка реестра могла бы говорить: «Member-only класс M-03: граница scope предлагаемого deliverable», указывать раздел и commit, публичное изменение и disposition. В ней не нужны имя, число членов, продукт или цитата из закрытого списка.

Если даже класс вопроса позволяет установить источник, описание следует сократить до минимального публикуемого состояния процесса. Слово «агрегировано» не устраняет риск обратной идентификации.

Рассмотренные источники не показывают, что закрытые комментарии по этой хартии фактически существовали. Доступность канала не равна его использованию. Общий реестр не должен придумывать невидимый материал.

Экспертиза имеет вес, но не создает неограниченных полномочий

Process требует учитывать законные взгляды и возражения не только активных участников, но и других сторон, включая публику. Специалист по доступности, безопасности, приватности, интернационализации или архитектуре способен выявить реальный пробел. Реализатор может доказательно оспорить срок.

Но экспертиза не делает автора политическим принципалом. Вес сообщения исходит из аргумента, фактов и последствий, а не из широкого ярлыка stakeholder.

В refinement Facilitator ищет консенсус участников. Team принимает отведенные ей решения и определяет следующий этап. Advisory Committee затем проводит формальный review, после чего возникает W3C Decision.

Реестр может показывать источник там, где это безопасно, но всегда должен показывать, какая роль ответила и какая власть закрыла состояние. Так публичная проверка не превращается ни в театр, ни в вымышленный народный мандат.

Минимальная схема общего реестра

Для каждого issue или безопасного класса нужны:

  1. устойчивый идентификатор;
  2. класс канала — public или Member-only — без личности и закрытого подсчета;
  3. безопасная публичная формулировка;
  4. точный раздел и commit проекта;
  5. ответившая роль и дата;
  6. PR, diff, альтернативный текст или причина не менять;
  7. disposition: принято, частично, без изменения, заменено, отозвано, отложено или не решено;
  8. требуемое Process состояние консенсуса;
  9. следующий уровень: дальнейший refinement, Team Decision, AC Review, продление или отказ;
  10. закрытие, преемник и исправления.

Тип канала — не вес. Member-only сообщение не выше решающей публичной технической рецензии; public сообщение не становится репрезентативным. Канал описывает хранение, а решение держится на обосновании и процедуре.

Фиксация версии предотвращает подмену. Open PR не равен merged тексту, merged текст не равен утвержденной хартии. Условие выполнено только тогда, когда изменение попало в продвигаемую версию.

Границы вывода

На 30 августа issue 564 и оба PR были открыты, документ 2026 года оставался draft. Страница группы показывала действующую хартию до 25 сентября.

Это не доказывает нарушение, чрезмерную задержку или техническую слабость. Refinement существует именно для незакрытых комментариев и patches. 7 сентября было приблизительной датой, а Process допускает объявленное продление.

Ссылка каталога на privacy носит контекстный характер. Она не идентифицирует W3C, Immersive Web Working Group или WebXR и не означает одобрения.

Рекомендация узкая: сохранить оба входа, соблюдать их режимы и опубликовать минимальный статус, достаточный для проверки происхождения одной хартии.

Источники

  1. W3C — начало refinement хартии Immersive Web, 10 августа 2026
  2. W3C — проект хартии Immersive Web Working Group
  3. w3c/strategy issue 564
  4. w3c/charter-drafts PR 831 — исходный проект 2026
  5. w3c/charter-drafts PR 862 — текст coordination
  6. w3c/charter-drafts PR 865 — описания спецификаций
  7. W3C Process Document, 18 августа 2025
  8. W3C — Immersive Web Working Group
  9. W3C — действующая хартия сентября 2024
  10. w3c/charter-drafts — история commits проекта 2026
  11. w3c/charter-drafts commit 488587ec141b — отметка DRAFT
  12. W3C — Horizontal Review
  13. Heng Lu — On the Multi-Stakeholder Mirage
  14. Heng Lu — On the Reality Layers of Internet Governance