club762.ruЗа последние три года команда обзора тем WordPress всячески старалась подтолкнуть авторов тем к использованию кастомайзера. В апреле команда приняла решение не просто «подталкивать» разработчиков, а потребовать переноса всех опций тем в кастомайзер. Несмотря на то что это решение «взращивалось» три года, у сообщества попросту не было возможности дать хоть какую-то обратную связь, пока решение не превратилось в обязательное требование.
Процесс разработки
Тот, кто следил за блогом команды обзора тем, видел предзнаменование этого шага. С выпуском WordPress 3.4 в 2012 году, в котором появился кастомайзер тем, команда провела обсуждение по предлагаемым изменениям в руководства обзора тем. Одно из предложенных изменений – рекомендация по внесению опций тем в кастомайзер. Особый интерес представляет собой разговор между Джастином Тэдлоком и Чипом Беннеттом по поводу того, нужно ли рекомендовать внесение опций в кастомайзер на таком раннем этапе.
В ноябре 2014 года команда провела встречу, чтобы обсудить модификации руководства по обзору тем. Вплоть до этого момента авторам тем разрешалось создавать опции темы с помощью одного из трех способов: при помощи кастомайзера, с помощью Settings API либо с помощью произвольных страниц опций, основанных на Theme Mods API.
Во время встречи Тэдлок внес предложение о том, чтобы команда «настоятельно рекомендовала» авторам тем использовать кастомайзер. Участники согласились с этим, и в итоге руководства обзора тем были изменены – в них добавился пункт о «настоятельной рекомендации» размещать опции темы в кастомайзере.
Спустя несколько дней после встречи Тэдлок опубликовал пост, в котором поставил вопрос о том, как решить проблему с опциями тем. Он акцентировал свое внимание на нехватке образовательных ресурсов, посвященных кастомайзеру, что и являлось, по его мнению, одним из основных врагов медленной адаптации кастомайзера.
«Я всегда рассчитывал на то, что команда обзора тем будет в большей степени образовательной командой. Я считаю, что если бы мы не сталкивались так часто с опциями тем, мы могли бы потратить больше времени на обучение пользователей в других сферах разработки/дизайна.
Я пишу этот пост, поскольку считаю, что это самая большая проблема с темами сегодня. И это самая сложная часть процесса обзора тем. Также это – одна из самых критически важных частей, поскольку опции тем зачастую несут в себе потенциальные проблемы с безопасностью».
Благодаря этому посту открылся диалог, позволяющий обсудить некоторые проблемы, связанные с переходом к использованию кастомайзера со стороны разработчиков. Беннетт опубликовал несколько дней спустя свой пост, в котором было приведено объяснение API, связанного с опциями тем. Позже Тэдлок привел пост о выборе между Theme Mods API и Settings API.
Голосование
Возвращаемся в апрель 2015. Команд провела встречу и единогласно согласилась потребовать от авторов тем перенести опции темы в кастомайзер. На следующий день Тэдлок объяснил, почему это изменение было внесено, и как команда пришла к такому решению.
«Во-первых, я хочу сказать, что это решение далось команде не так просто, и мы не торопились с ним. Фактически, оно стало итогом обсуждения, которое шло в течение трех лет (с того момента, как кастомайзер появился в ядре). Многие из нас с самого начала надеялись, что мы сможем придерживаться более органичного подхода к этому, и разрешим авторам тем сделать переход в течение определенного времени»
Решение вылилось в активное, длительное обсуждение с многочисленными людьми.
Введение периода RFC
В блоге команды обзора тем есть несколько записей, в которых всячески поощряется и поддерживается обратная связь, особенно по предложениям в руководства. Однако в данном случае обратная связь, вопросы и критика не были поддержаны до того момента, пока решение не было принято.
Команда обзора тем обычно публикует программу, в которой отмечает, какие темы будут обсуждаться во время встречи. Программа была опубликована только для встречи 14 апреля. Для встречи 21 апреля программы не было. Это означает, что свое мнение смогли озвучить только те люди, которые занимаются продвижением этого решения. Мнение остальных не было учтено, поскольку не было никаких предварительных уведомлений о данном событии.
Я понимаю, что команда обсуждала это изменение в течение последних трех лет, однако я хотел бы видеть период RFC, который составлял бы, по крайней мере, месяц.
В итоге, пользователи смогли бы прокомментировать решение прежде, чем оно будет реализовано. Команда, возможно, могла бы предложить более доступный способ участия в обсуждениях, не такой сложный, как Slack. Также ей стоило бы прислушаться к вполне понятным переживаниям со стороны разработчиков тем.
Я надеюсь, что такие крупные изменения, как то, что описано в статье, будут впоследствии решаться с привлечением широкой общественности. Мнение о том, что заинтересованные стороны должны обязательно присутствовать в Slack во время встречи, чтобы озвучить проблемы перед принятием финального решения, попросту недопустимо. У людей всегда есть свои дела. Да, Slack удобнее и проще в использовании, чем IRC, однако запись в блоге с формой комментирования является более доступным способом выражения своих мыслей для многих людей.
Период RFC подойдет далеко не для всего, что происходит в мире разработки WordPress, однако изменения, которые затрагивают текущие, прошлые и будущие темы в каталоге – яркий пример того, где такое нововведение имело бы смысл.
Источник: wptavern.com
