Эффективная работа над стандартами, часть 2: трудный путь к компромиссу
Перевод статьи Effective Standards Work, Part 2: Threading the Needle с сайта infrequently.org для css-live.ru, автор — Алекс Рассел
Нас слишком часто не устраивает процесс стандартизации в вебе. Этот цикл статей рассматривает, какие силы в этом участвуют, как мы улучшаем ситуацию, и как можно эффективнее направлять развитие новинок.
В первой части («Оперативная обстановка») речь шла о постоянных вызовах для стандартов и о силах, порождающих недоразумения. В ней также описывалась динамика экосистемы, из-за которой менять что-либо так трудно, даже если не брать в расчет изменчивых корпоративных стратегий браузерных компаний.
Важнейшие ингредиенты
Продвигать новые функции в такой среде чрезвычайно сложно. Однако, вооружившись четким пониманием ситуации, можно наметить узкую, но надежную дорогу для дальнейшего пути. Необходимые ингредиенты для решения задач в веб-платформе включают в себя:
- Готовность к неудачам с минимальными потерями
…как минимум на ранних этапах. Среди идей и проектов очень мало хороших, и даже те из них, что мы в итоге принимаем, редко бывают хорошими с самого начала. Для улучшения результатов необходимо, чтобы идеи где-то могли рождаться и тихо кануть в историю, либо радикально меняться без лишнего драматизма вокруг. - Участие веб-разработчиков и разработчиков браузеров
Без обеих групп за одним столом ничего хорошего не выходит. - Площадка вне официальной Рабочей группы для проектирования и экспериментов
Когда результаты определены заранее, вряд ли стоит ждать новых озарений и подходов. Долговременные отношения участников рабочих групп также нередко вредят новым идеям. Никто не учится азам танца сразу на большой бродвейской сцене. Начинать надо с чего-то маленького и шустрого, а потом постепенно достраивать его. - Путь к итоговой стандартизации
Нужно позаботиться, чтобы в будущем обязательства по интеллектуальной собственности выполнялись, даже если ранняя, черновая разработка велась без строгой политики в отношении интеллектуальной собственности. - Личное обсуждение
Я не видел, чтобы работа по проектированию хорошо начиналась без персонального сотрудничества. Как минимум, это поддерживает человеческие взаимоотношения, необходимые для совместного рассмотрения альтернатив.
Заманчиво думать, что проектирование может (или должно) вестись в рамках формальной Рабочей группы. Продуктивные рабочие группы должны включать и разработчиков, и реализаторов, в конце концов. В таких группах часто проходят личные встречи, и путь к стандартизации на таких площадках короче всего! Но это не работает; во всяком случае, этого часто оказывается недостаточно.
Начинать здесь — путь к боли и неудаче. Почему? Весь расклад играет против коллективного проектирования, и организационно, и процедурно.
Организационно, задача Рабочей группы — оценивать то, что предлагают включить в стандарт. Для включения почти во все стандарты, что я знаю, нет строгой или научной основы. Свидетельство — (еще) не достаточный аргумент. Принятые в организациях по стандартам нормы определяются главным образом социальными взаимосвязями между теми, кто поддерживает свои системы и старается их улучшать. Чем старше спецификация и чем стабильнее состав группы, тем труднее новым идеям и людям до нее достучаться.
Очередная трудность в этих группах для всех, кроме разработчиков реализаций («клиентов», как сказали бы в другой вселенной) — асимметричный поток информации в отношениях производитель/клиент. Создатели реализаций считают себя обязанными сопротивляться проектам, в которых они видят угрозу для своей архитектуры или угрозу в конкуренции. Новые идеи должны попадать в эту среду уже более-менее «готовыми», чтобы о них вообще заговорили.
Процедурно, задача руководства и группы в целом — приближать выпуск ранее обещанных документов. Уставы Рабочих групп обычно задают некое расписание, и хотя в этих делах хватает своих тонкостей, группы, переставшие выдавать новые версии на регулярной основе, считаются проблемными. И организационная поддержка проблемных групп имеет склонность заканчиваться, а без нее им не продолжить.
Ошибки и новые итерации — жизненная основа хорошего проектирования, но эти группы ориентированы только на успех. Они агрессивно отфильтровывают новые идеи ради того, чтобы и дальше выпускать новые версии спецификаций. Если что-то закрепилось в повестке рабочей группы, то это насовсем. Это принципиальная противоположность итеративности.
Если вы не бывали на реальных совещаниях по стандартам, легко вообразить себе что-то вроде утонченного интеллектуального клуба, где спонтанно возникают блистательные идеи и в мгновение ока складывается идеальный консенсус. Это полная противоположность тому, что происходит в действительности. На самом деле время на обсуждение обновлений и погружение в нюансы предлагаемых изменений легко может поглотить всё запланированное время. А это время стоит дорого! Даже когда участникам не нужно далеко ехать ради встречи, рабочий график на их должностях бывает до нелепого плотным. Не забывайте, что для большинства самых востребованных членов групп — председателей, инженеров из важнейших фирм — это не основная работа. Работа над стандартами отнимает время от повседневных задач, так что без учета времени и расходов никак. Еще до начала совещания каждый уже знает, какие важные темы будут обсуждаться, и если отнять бесценное время от решения этих вопросов — в частности, на рассмотрение «сыроватых» идей — важные персоны (и команды, которые они представляют) будут огорчены. Не лучший рецепт для согласия.
Мысль, будто проектировать что-либо лучше всего на публичном форуме с председателем, расписанием, протоколом заседаний и переполненной повесткой дня, где полно влиятельных фигур, привыкших говорить «нет» — это бред какой-то. Политические решения не выдумываются на открытых заседаниях в парламентах или ООН; там их скорее выносят на рассмотрение и голосование, разве что, может, с небольшими дополнениями.
Примечание: есть много неработоспособных групп по стандартам, у них обычно повестка дня меньше или, наоборот, масса пустой работы ради работы. К таким группам вряд ли будут прислушиваться разработчики реализаций. Группы, не способные надолго заинтересовать разработчиков реализаций, не стоят того, чтобы уделять им время.
Вот почему команда Chrome теперь настаивает на том, чтобы проектирование велось на «инкубационных» форумах. Они могут быть встроены в формальный процесс рабочей группы (как в TC39) или на отдельных форумах, откуда информация поступает в формальные, официальные группы (напр. WICG или RICG)
Семь раз спроектируй, один раз выпусти и стандартизируй
Из всех попыток развивать веб-платформу за прошедшее десятилетие я извлек урок в виде такого до обидного короткого (учитывая, какой боли стоило каждое осознание) списка:
- Начинайте проектирование в маленьких, специально выделенных группах
- Разрабатывайте открыто, но подальше от ярких огней большой сцены
- Делайте больше итераций с самого начала, потому что если что-то попало в веб — это навсегда
- Ставьте возможную интероперабельность на первое место: если разработчики браузера говорят «это работать не будет», верьте им!
- Дайте попробовать ограниченной аудитории как можно раньше ради обратной связи
- Подкрепляйте стандарты свидетельствами и отзывами разработчиков с каждой итерации
- Ставьте интероперабельность выше идеальной спецификации: тесты дают такую же или даже лучшую совместимость, чем строгие формулировки или идеальные абстрактные схемы
- Расставляйте точки над «i»: официальные Рабочие группы и широкое обсуждение — важные способы улучшить ваш проект на следующих этапах.
Эти пункты вытекают из нашей цели, перевешивающей всё остальное: выпустить правильную вещь.
Слишком уж часто мы видели наработки (эх, зачем вспоминать AppCache), которые можно было бы улучшить, если прислушаться к обратной связи. Процессы проектирования, где не участвуют веб-разработчики, часто терпят крах, потому что ошибку в них не исправить. Разработчики браузеров лучше чувствуют ограничения своей системы, а не реальность веб-разработчиков. Без голосов веб-разработчиков на первый план выходит легкость реализации функции, а не ее соответствие задаче. Слишком часто срабатывает ловушка группового мышления, поскольку участники процесса видят его однобоко, отчего менять что-либо и пробовать заново оказывается труднее.
Аналогично, работам по проектированию без участия реализаторов не хватает ограничений, делающих проект успешным. Предложения без такой «земли» под ногами пишутся легко. Велик соблазн собрать группу для проектирования будущих API в вакууме, но без реализации критическая масса никогда не набирается.
Так как же вам, веб-разработчику, творить будущее веб-платформы?
Первое, что нужно понять — разработчики браузеров хотят решать важные проблемы, но могут не знать, какие проблемы стоят их времени. Прогресс в общении с разработчиками реализаций часто зависит от того, дойдет ли до них, сколько плюсов принесет решение проблемы. Сами они этого не чувствуют, так что вам может понадобиться их убедить!
Достичь этого взаимопонимания — процесс социальный. Доступные и объективные свидетельства могут быть важным подспорьем, но истории тоже важны. Труднее добиться, пожалуй, чтобы их увидела доброжелательная аудитория внутри браузерной команды. К счастью, у разработчиков действующих браузерных движков в штате есть технические евангелисты и группы по связям с разработчиками (привет вам, @ChromiumDev, @mozappsdev, MSEdgeDev и Джонатан!). Аналогично, если вы работаете в веб-фирме из первой тысячи, у вашей команды уже, возможно, есть контакт с партнерской командой браузера. Такие команды могут перенаправить любой толковый вопрос нужным инженерам.
Другие модели совместной работы на ранних этапах включают кулуарные беседы на отраслевых мероприятиях, напр. TPAC или BlinkOn. Специализированные механизмы для этого вроде практических занятий W3C организовать в чем-то труднее, но разработчики браузеров охотно в них включаются. Не могу говорить за все браузеры, но как минимум хромовцы охотно приезжают и на внеплановые мероприятия, чтобы решать вопросы на ранних этапах проекта. Эндрю Беттс мастерски провел подобное мероприятие в офисе издания Financial Times, дав начало тому, из чего выросли сервис-воркеры. Пускай у вас нет такой кучи связей, как у Эндрю, но вы можете знать кого-то, у кого они есть. Помните, поначалу всё зависит от отдельных людей. Привлечь внимание к вопросу, который вам кажется важным, значит собрать небольшую группу людей с близкими взглядами. Найти «своих» людей нелегко, но далеко не невозможно!
Далее, учтите что фазы проектирования, разработки, новых итераций и конечной стандартизации требуют времени. Иногда много времени. Маловероятно, что вы, как веб-разработчик, сможете поддерживать интерес к этому процессу, ведь это не принесет вам никакой практической пользы в текущем (и даже следующем) проекте. Это не личный провал, просто так уж оно всё устроено. У вас есть информация, которой нет у разработчиков браузеров, но ресурсов и времени у вас меньше. Если направить их на верный путь, это поможет кому-то еще, и, если это — ваша профессия, в конечном счете может помочь и вам. Не вините себя, если в какой-то момент вам придется выпасть из процесса.
С каждой новой итерацией сохранять интерес становится всё проще. После первых встреч появляются первые наброски спецификаций, часто их выкладывают на GitHub, где можно их комментировать. На форумах типа WICG можно оставлять обратную связь прямо во время разработки — намеренный шаг со стороны команд Chrome и Edge, чтобы лучше слышать голоса разработчиков, пока наброски еще легко можно изменить..
Следующим шагом, Chrome сейчас запускает серию «начальных пробников» (Origin Trials), идея, позаимствованная у Джейкоба Росси из Microsoft. «Начальные пробники» позволяют разработчикам тестировать новинки на живых сайтах и направлять их эволюцию. Команды, выпускающие эти «пробники», сами активно умоляют об обратной связи и часто учитывают ее, меняя код.
Внимательные читатели заметят, что ничто из этого не требует вступления в Рабочую группу или постоянного сидения в списке рассылки. Влиять на траекторию веб-платформы никогда не было проще, даже если вы знаете, с какой стороны подступиться к усилителю (Алекс использует метафору усилителя для «традиционных» организаций по стандартам, см. первую часть статьи — прим. перев.).
«Выпустить правильную вещь»
Эти относительно новые возможности для участия вне формальных процессов специально созданы для того, чтобы роль разработчиков и свидетельств из практики в процессе проектирования стала важнее. Мы поддерживали их создание, потому что они помогают нам отделить открытое проектирование с его итерациями от стандартизации, чтобы каждый процесс помогал сообществу улучшать новинки в тот момент, когда это эффективнее всего.
Эти процессы никоим образом не идеальны, и полагать, будто браузеры и стандартисты все как один согласны с идеей проектирования в «инкубаторах» вне формальных Рабочих групп — эпичнейшая недооценка реальности. Работа по поддержке — отдельная сложная тема. Тем не менее, команда Chrome накопила немало убедительных доказательств, что этот подход к работе лучше других.
Поощрение сотрудничества, итераций и практических свидетельств позволило нам настроить процессы на поддержку этих ценностей. «Инкубация» и всё с ней связанное позволяют нам быстрее реагировать на запросы разработчиков, одновременно повышая уверенность, что новинки, выпускаемые в стабильном релизе, с толком решают проблемы, которые стоит решать. Надеюсь, эта серия статей поможет нам лучше понимать, к какому будущему мы идем. В конце концов, все мы хотим выпустить правильную вещь.
Я начинал и переписывал варианты этой статьи почти 4 года. Я тогда пообещал десятку людей (а то и больше), что работаю над статьей про эти вопросы, но по ряду причин из тех, что я упомянул вначале, у меня никогда не оказывалось подходящего времени, чтоб нажать кнопку «Опубликовать». Прошу прощения у этих людей за задержку.
Есть немало критики формальных стандартов и де-факто ограничительных процессов, в которых они создаются, вообще, как явления. Эти статьи обходят эту тему, потому что иначе понадобилось бы долгое отступление об антимонопольных законах и правилах конкуренции. Достаточно сказать, что я лично глубоко заинтересован в работе над будущим веб-платформы, и изменения в подходе Chrome к стандартам, описанные выше, специально делались для того, чтобы подключаться к работе с ними могло больше разных людей, и чтобы фактические свидетельства играли в этом большую роль.
Большое спасибо Эндрю Беттсу, Брюсу Лоусону, Крису Уилсону и Марико Косаке за вычитку черновиков этих статей и исправление многих ошибок в них.
P.S. Это тоже может быть интересно: