Кратко

  • Процесс W3C требует своевременно принять достаточные меры, если отменённое решение уже вызвало последствия, и не считает поддержанные части возражения полностью урегулированными до этого. Единого публичного доказательства перехода к закрытию он не определяет.
  • По Vibration API последовали реальные действия, включая завершение отчёта о реализациях. Но их приходится собирать из отчёта Совета, технической задачи, задачи по уставу, pull request и стратегического обсуждения, не находя одного полномочного акта закрытия.
  • Нужна версионируемая запись хранения мер Совета: она должна отделять необязательную рекомендацию от решения компетентного органа и связывать каждый поддержанный довод с ответственным, полномочием, сроком, доказательством и датой закрытия.

Отмена решения не отменяет его следов

Совет W3C рассматривает Formal Objection, когда обычные попытки достичь согласия не дали результата. Совет подтверждает или отменяет оспариваемое решение. Те доводы возражения, которые оправдывают отмену, считаются поддержанными.

Но отмена полномочия решения не перематывает уже совершённые действия. Текст мог попасть в публикацию, спецификация — перейти в иной статус, а программа группы — быть построена по уставу. Эти последствия требуют отдельной работы.

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

Так возникает открытое состояние после решения Совета. Оно названо, но для него не предусмотрен обязательный публичный носитель от начала до конца.

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

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

Три критерия требуют трёх видов доказательств

«Достаточная» мера должна отвечать каждому поддержанному аспекту, а не просто создавать активность в репозитории. Нужна связь между доводом, оставшимся последствием, выбранным действием и результатом.

«Своевременно» не означает один срок для всех случаев. Исправление фразы и поиск новой технической траектории занимают разное время. Но можно назначить цель конкретного дела, следующую дату проверки и объяснить задержку.

«Полностью рассмотрено» — конечный статус. В цитируемом положении не сказано, кто его устанавливает, где публикует, как уведомляет заявителя и исходного автора решения и как исправляет ошибочное заключение. Есть название финиша, но нет предписанного финишного акта.

Vibration API показывает разрыв на практике

В конце 2024 года Advisory Committee рассматривал предложение сделать Vibration API (Second Edition) Obsolete Recommendation. Поступили два Formal Objection. Devices and Sensors Working Group на TPAC 2024 решила откатить документ и продолжить работу в виде нового Candidate Recommendation Snapshot. Одно возражение удалось урегулировать, второе передали Совету.

10 августа 2025 года Совет поддержал оставшееся возражение. В отчёте он отметил уже изменившееся состояние: документ находился на стадии Candidate Recommendation Draft, которую по указанной норме нельзя было объявить устаревшей. Группа уже откатила спецификацию, чтобы продолжить работу и ответить на опасения.

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

Дальнейшая работа видна. Issue 33 закрыли как выполненный 1 мая 2026 года после подготовки отчёта о реализациях. Процесс устава 2026 года сослался на рекомендацию Совета. Issue 781 отслеживал план и отчёт. Позже pull request 809 предложил явные траектории для спецификаций с единственным движком, включая изменение статуса Vibration при отсутствии второй реализации, но был закрыт без слияния. Более широкий устав продолжил меняться и прошёл рассмотрение Advisory Committee.

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

Был ли прежний откат уже смягчением или временным ограничением последствий? Закрытие issue 33 урегулировало один поддержанный довод или лишь предоставило материал для следующего решения? Выполнена ли рекомендация по плану в другом тексте, заменена иной консенсусной мерой или ещё не получила полномочного вывода?

Отчёт Совета доказывает решение и рекомендации. Team report даёт историю. Техническое issue показывает одну задачу, charter issue — требование участника проверки, pull requests — варианты текста, strategy issue — общий ход устава. Ни один документ не обозначен как главный реестр статуса «полностью рассмотрено».

Открытое issue не доказывает нарушение. Закрытое issue не доказывает институциональное закрытие. Даже слитое изменение подтверждает текст, а не автоматически достаточность. Не хватает полномочной связки.

Обсуждение issue 751 установило пределы

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

Публичные ответы разделили две вещи. Конкретное предложение Совета не обязательно: ответственный орган может выбрать другое консенсусное решение. Однако из необязательности предложения не следует право оставить последствия отменённого решения без внимания. Их надо отменить, нейтрализовать или смягчить, а Team должна не дать задаче забыться.

Team отслеживает, а не пишет. В обсуждении назывались существующие рычаги: напоминание председателю, действующее полномочие назначения, остановка публикации при несоблюдении transition requirements, процедуры отката и прекращения работы. Нового права переписывать спецификацию или стирать историю публикации не возникает.

При этом несколько участников считали поток недостаточно ясным. Роль исходного автора решения следовало показать прямо; иначе вопрос будто передаётся Team, после чего «происходит магия». Защитники текста отвечали, что содержание верно, а общность нужна для разных типов решений. Улучшение отложили как редакционное.

Практический принцип сформулирован там же: заявитель не должен месяцами или годами самостоятельно следить за выполнением поддержанного возражения. Это не право вето на исправление. Это обязанность института публиковать состояние.

Лучший довод в пользу нынешней схемы

Не каждое возражение относится к Working Group. Исходным решающим органом могут быть группа, председатель, Team, TAG, AB или орган, готовящий устав. Единая отправка в рабочую группу иногда была бы ошибочной.

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

Эти доводы оправдывают лёгкую и адаптивную запись с обозначенной зоной конфиденциальности. Они не оправдывают закрытие, которое читатель должен угадывать.

Что должно быть в записи хранения мер

Если Совет отменяет решение с существующими последствиями, его отчёт должен открыть версионируемую запись. Team ведёт состояние, а каждая ответственная сторона добавляет своё решение и доказательства.

Нужны следующие поля:

  • отчёт Совета, дата и версия Процесса;
  • отменённое решение и все поддержанные аспекты;
  • существующие последствия и затронутые документы или процедуры;
  • ответственная институциональная роль для каждой меры;
  • уже существующее полномочие этой роли;
  • предложение Совета с явной отметкой о необязательности;
  • принятое, изменённое или альтернативное решение;
  • зависимости, цель или следующая проверка, состояние и причина задержки;
  • публикация, продвижение или устав, удерживаемые до выполнения меры;
  • критерий приёмки и доказательство для каждого аспекта;
  • уведомление или консультация заявителя и исходного решающего органа с учётом конфиденциальности;
  • орган, полномочный признать меру достаточной;
  • датированное заявление о закрытии либо прямое указание, что его ещё нет;
  • исправления, последующие решения, appeals и новые Formal Objections;
  • граница публичной и ограниченной информации.

Запись не превращает совет в приказ. Она может зафиксировать иной путь группы и доказать, что он отвечает тому же доводу. Она не создаёт новый appeal: новое исполняющее решение остаётся в обычной процедуре. И она не расширяет власть Team, поскольку каждое действие должно ссылаться на прежнее полномочие.

Главное — отделить работу от результата. Встреча, issue и patch показывают движение. Достаточность появляется, когда доказательство проверено против поддержанного аспекта.

Границы доказанного

Публичные источники не показывают, что W3C нарушил внутренний срок, что меры по Vibration до сих пор недостаточны или что конкретный участник уклонялся от решения Совета. Выполнение issue 33 и открытое состояние issue 781 — разные факты; ни один не устанавливает конечный статус Процесса.

Закрытие pull request 809 без слияния не доказывает его содержательное отклонение или отсутствие равноценного плана. Более поздние споры вокруг устава 2026 года включали темы за пределами Vibration и не могут ретроспективно служить обвинением.

Вывод структурный: W3C описывает состояние после решения Совета, но не требует публичной записи, которая ведёт его до закрытия.

Источники

  1. W3C Process от 18 августа 2025 года — меры после решения Совета
  2. Текущий Editor’s Draft W3C Process — меры
  3. Process issue 751 — последствия решения Совета
  4. Руководство W3C — Formal Objections и Council
  5. Council Report по Vibration API, второй раунд
  6. Team report по возражению Vibration API
  7. Vibration issue 33 — обновление отчёта о реализациях
  8. Charter issue 781 — план, рекомендованный Советом
  9. Strategy issue 530 — устав Devices and Sensors WG 2026
  10. Pull request 809 — планы по отдельным спецификациям
  11. Guide issue 173 — кто принимает исходное решение
  12. Process issue 1029 — когда публиковать Council Report
  13. Heng Lu — The Multi-Stakeholder Mirage
  14. Heng Lu — On the Agency Problem at the Core of Internet Governance