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

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

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

Блог Миши Рудрастых

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. Во вкладке перечислены функциональные плагины, доступные для тестирования.

FeaturedPlugins

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

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

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

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

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

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

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

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

Понравилась статья? Поделиться с друзьями:
Комментарии: 1
  1. Petrozavodsky

    Походу кур на включение в ядро только свистоперделок интерфейса будет продолжен

Добавить комментарий

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