Модель Features as Plugins – сплошной хаос

Выпущенный в конце 2013 года, WordPress 3.8 включал в себя новые особенности, такие как новый браузер тем, инструмент выбора областей виджетов, а также редизайн бэкэнда. Также это первый релиз, отличающийся новой схемой добавления возможностей, которая стала называться «features-as-plugins» («возможности как плагины»). Редизайн бэкэнда начался с появления плагина MP6, разработка которого стартовала в марте 2013 года.

До MP6 все возможности в основном разрабатывались в ядре в процессе цикла разработки. Данный метод привел к тому, что некоторые версии WordPress выходили с задержкой, как это случилось с WordPress 3.6. Успех MP6 доказал, что разработка базовых возможностей в виде плагинов упрощает их тестирование, обслуживание и последующее введение в ядро. Начиная с принятия процесса разработки, в ядро попало как минимум семь возможностей. Однако, если посмотреть на это со стороны, можно сказать, что данный процесс оказался неудачным.

MP6 задал планку

Каждую неделю Мэтт Мулленвег и Мэтт Томас выпускали новую версию плагина для тестирования. Они также постоянно информировали аудиторию обо всех изменениях, оставив форму комментирования для обратной связи. Это позволило людям поучаствовать в процессе разработки и тестирования. С помощью P2 и секции комментариев стало гораздо проще поддерживать обратную связь. Поскольку MP6 был плагином, его тестирование было очень простым – для этого достаточно было установить его в обычную сборку WordPress.

Нехватка аудитории для тестирования

MP6 был доступен для скачивания в каталоге плагинов WordPress. В итоге любой мог взять его и протестировать. Недавно вышедшие плагины, такие как User Session Manager от Джона Блэкберна, не имеют каких-либо записей P2 на сайте Make WordPress Core. Как и в случае с некоторыми другими возможностями, дискуссии проходили в тикете trac. Разработка плагина была перенесена в Github, пока он не появился в ядре. Доступность плагина только на Github, а также недостаток обсуждения данной возможности привели к тому, что многие люди просто не смогли стать частью группы тестирования.

Ведущий разработчик WP, Райан Борен, отметил в одной из тем в ноябре 2014 года, что ни один плагин не достиг стандартов, заданных MP6, в плане привлечения аудитории для тестирования. Для плагинов, которые планируется включить в ядро, Борен предложил следующие обязательные пункты:

• Присутствовать в обновленном виде в каталоге плагинов
• Быть готовым к работе на мобильных устройствах, как и на настольных компьютерах
• Иметь визуальные записи для главных потоков по всем новым интерфейсам для всех устройств
• Обладать продуманным, современным интерфейсом
• Иметь историю публикации еженедельных обновлений в make/core
• Иметь историю регулярных обновлений каталога с плагином
• Иметь аудиторию для тестирования
• Опубликовать в блоге make/core запись с предложением по введению плагина в ядро, дополненную визуальными заметками и остальными деталями
• Существовать в течение как минимум одного релиз-цикла. Плагины, созданные в начале релиз-цикла, нельзя рассматривать на внесение в ядро до следующего релиза.

Некоторые функциональные плагины не придерживаются многих из этих пунктов. В июне 2014 года Эндрю Нейсин добавил вкладку «Бета тестирование» к экрану Add Plugins (Установить плагины) для тех, кто использует транк WordPress. Во вкладке перечислены функциональные плагины, доступные для тестирования.

Как следует из скриншота, практически все функциональные плагины мертвы, включая и WP API. Однако, если вы посмотрите на активность в Github по WP API, то вы увидите, что плагин постоянно дорабатывается. Каким образом многие люди могут поучаствовать в процессе тестирования, если функциональные плагины не обновляются и не доступны для скачивания в каталоге? Это нужно изменить как можно скорее.

Функциональные плагины – это скорее эксперимент

Функциональные плагины не имеют никаких гарантий по добавлению в WordPress. Вместо этого процесс их тестирования напоминает лабораторный эксперимент. Иногда сам плагин не входит в ядро, а его части включаются. К примеру, многие улучшения редактора записей в версиях 3.9, 4.0 и 4.1 были взяты из Front-end Editor. Возможно, команда разработчиков должна подумать над тем, чтобы переименовать функциональные плагины в функциональные эксперименты, поскольку это лучше отражает их суть.

Управление проектом

Когда я начал обсуждение разработки функциональных плагинов 7 января на встрече разработчиков ядра, Скотт Тейлор высказал точную мысль: «Функциональные плагины зачастую превращаются в проекты, которые не имеют никаких требований или задач, они никак не запланированы и зачастую требуют бескомпромиссного принятия». Функциональные плагины обычно поддерживаются одним или двумя людьми, которые могут быть прекрасными разработчиками, но при этом иметь слабые навыки в плане управления проектом. Нужен кто-то, кто будет постоянно присматривать за функциональными плагинами, чтобы убедиться в том, что они следуют расписанию и размещаются на одной странице в актуальной версии.

Процесс надо исправить

Ясно, что процесс разработки функциональных плагинов в данный момент достаточно хаотичный. Не хватает коммуникации, отсутствует синхронизация между плагинами на Github и WordPress.org, некоторые плагины вводятся в ядро слишком быстро. Если пользователи должны получить максимум выгоды от процесса экспериментирования, его нужно лучше организовать. По крайней мере, команда разработки знает о проблемах и работает над улучшением ситуации для цикла разработки 4.2.

Источник: wptavern.com