Группа по взаимодействию с PHP Framework (PHP-FIG или просто FIG для краткости) находится на распутье. Многие электроны были принесены в жертву, говоря о несчастьях ФИГ в последнее время, но, к сожалению, большая часть этого была FUD, с небольшим усилием, потраченным на позитив. По приглашению SitePoint я хотел бы предложить более позитивный взгляд на FIG и сообщество PHP и продемонстрировать, почему FIG может и должна продолжать оказывать положительное влияние на экосистему PHP.
В качестве вступления, я являюсь представителем FIG в Drupal, и с ноября 2009 года я постоянно нахожусь, сейчас мне всего 7 лет, что делает меня одним из самых продолжительных представителей FIG. Я был редактором PSR-6 и нынешним редактором PSR-13, а также помогал, в частности, в спецификациях PSR-3 и PSR-7. Вместе с Филом Стердженом я помогал спроектировать текущий рабочий процесс FIG для PSR. Со стороны Drupal, я был одним из главных драйверов Drupal 8, приняв PSR-0 и PSR-3.
Неудобное начало
FIG была основана в 2009 году под названием «Группа стандартов PHP» после первой встречи на php [tek] в Чикаго в мае. Первоначально он был настроен со списком рассылки по адресу standard@lists.php.net, с целью создания его первой спецификации — стандарта автозагрузки PSR-0 — и, вероятно, других как стандартов для всего сообщества.
Неудивительно, что «кто, по вашему мнению, вы?», Реакция на это предположение была быстрой и решительной, и группа была быстро отброшена с lists.php.net, вместо этого настроив группу Google для координации. В течение следующих нескольких лет Группой стандартов PHP было сделано еще немного, кроме как допустить несколько дополнительных людей / проектов в конце 2009 года (в том числе и ваш, представляющий Drupal). Группа стандартов PHP еще не заслужила право называть себя так в глазах сообщества.
Медленный, но устойчивый рост
Перенесемся в октябрь 2011 года. После двух лет полной смерти группа снова начала оживать. Он переименовал себя в «менее интернациональную» группу, которая, как мы надеемся, стала менее противоречивой, хотя у нее все еще не было ни действующего устава, ни определенного заявления о миссии, вместо этого он работал над тем, «над чем мы решаем работать». Среди спецификаций, которые рассматривались в этот период были стандарты кодирования PSR-1, стандарты стиля кодирования PSR-2 и интерфейс протоколирования PSR-3 .
Были некоторые споры о том, были ли интерфейсы даже «честной игрой» для определения ФИГ, поскольку в ней не было формулировки миссии. Поэтому в марте 2013 года я провел опрос, чтобы определить, предпочитают ли участники ФИГ (как участники проекта, так и другие) «мягкие спецификации» (например, стандарты кодирования) или «жесткие спецификации» (например, интерфейсы), и результаты вернулись к «Все вышеперечисленное, но со склонностью к интерфейсам». Аналогичный опрос , проведенный вскоре после этого, показал скромное стремление к перспективным, но основанным на практике спецификациям (вместо того, чтобы «документировать только то, что было сделано» или «создавать новые вещи из цельной ткани»).
Несмотря на «каркас» в названии, FIG также никогда не ограничивался только «каркасными» проектами. Помимо того, что с самого начала это слово было крайне плохо определено, членство в FIG быстро выросло до такой степени, что члены с чисто структурной структурой были явным меньшинством наряду с автономными библиотеками, CMS, вики, пакетами электронной коммерции и другими автономными приложениями. , Преимущества сотрудничества и взаимодействия не ограничиваются «рамками».
Участие в ФИГ также было плохо определено. Первоначальные основатели были в основном руководителями проектов, но не полностью. В начале было много споров о том, были ли участники «людьми» или «проектами»; то есть послы членов ФИЖ действовали от имени своих проектов, или они просто были людьми, которые были «достаточно крутыми», чтобы иметь возможность голосовать за жизнь благодаря тому, что руководили проектом? Это было поставлено на голосование в апреле 2013 года, и в устав были внесены четкие поправки, чтобы сделать голосующих представителей послами от имени своего проекта. Несмотря на очевидный результат, немногие избранные отказались признать это решение и действовать так, как будто его никогда не было; в их утверждениях была некоторая обоснованность, так как на практике каждый всегда взаимодействует с человеком, а не с «проектом», а люди — это люди, но группа и устав говорили.
Другой проблемой, которая возникла, было право собственности на спецификацию в разработке. Технически никто ни за что не отвечал, поэтому у нескольких спецификаций (которые стали стандартом автозагрузки PSR-4 и стандартом кэширования PSR-6) было несколько конкурирующих версий от разных людей, и никто не мог отследить, какая из них была «настоящей» версией. , Ясно, что это было неоптимальным.
Поэтому в июле 2013 года группа приняла новый устав рабочего процесса, автором которого в основном был Фил Стерджон и я, который определил явного редактора, координатора и спонсора проекта PSR, создав каркас рабочей группы. В соответствии с этой моделью группа прошла стандарт автозагрузки PSR-4, стандарт кэширования PSR-6 и стандарт обмена сообщениями HTTP PSR-7 .
Влияние всего сообщества
Разные PSR, опубликованные FIG, конечно же, повлияли на сообщество PHP далеко за пределами нескольких проектов-участников. Определенные стандарты в вакууме имеют способ сделать это.
- PSR-0 был ключевым активатором для Composer, который преобразовал экосистему PHP.
- PSR-1 и PSR-2 вместе теперь являются предустановкой во многих IDE, что делает их стандартом кодирования по умолчанию почти для всех проектов PHP (за исключением немногих избранных с массивными базами кода, предшествующими PSR-2, для которых переключение нецелесообразно, несмотря на давление сделать это).
- По словам Пакаджиста , регистратор PSR-3 был установлен более 37 миллионов раз. Для PSR-7 это около 11 миллионов.
- Стандарт обмена сообщениями по протоколу HTTP PSR-7 породил небольшую индустрию экспериментов с промежуточным программным обеспечением HTTP, которое в той или иной степени уже было принято многими, если не большинством крупных проектов.
Несмотря на спорных начала, фиги фактически становятся Телом стандартов для PHP. Чтобы заработать, потребовалось время, но благодаря работе десятков людей, как членов ФПГ, так и нет. Тема Reddit, начавшаяся в январе прошлого года, показала, что, хотя и не универсальная, для FIG было явное предпочтение подняться и официально принять эту роль.
На сегодняшний день FIG имеет ряд спецификаций на разных стадиях разработки, начиная от только начинающих до почти завершенных, включая:
- PSR-9 ( фон ) и PSR-10 ( фон ) — отчеты по безопасности и автоматические рекомендации по безопасности.
- PSR-11 ( фон ) — функциональная совместимость контейнера инъекций зависимости.
- PSR-12 ( фон ) — пересмотр стандартов кодирования с учетом PHP 7.
- PSR-13 ( фон ) — обработка гиперссылок.
- PSR-14 (на заднем плане ) — менеджер событий / диспетчер.
- PSR-15 ( фон ) — промежуточное ПО HTTP для PSR-7.
- PSR-16 (в фоновом режиме ) — упрощенный интерфейс кеша в простом кейсе (разработанный для удобной упаковки PSR-6).
- PSR-17 ( фон ) — фабрики HTTP для PSR-7.
Большинство редакторов этих предложений сами не являются членами ФИЖ. Каковы бы ни были намерения первоначальных полдюжины людей, ФИГ уже давно вышла за рамки своих скромных начинаний.
Растущая боль
Тем не менее, внутренний процесс FIG не вырос вместе с группой. Первоначально смоделированный на основе хаоса PHP-Internals, он принял процесс по мере необходимости. (Хотя, возможно, точнее было бы сказать, что изначально оно не было смоделировано на чем-то ином, чем «у нас есть список рассылки».) В последние годы многие люди указывали на структурные проблемы FIG.
- Быть руководителем проекта не обязательно делает кого-то лучшим в разработке стандартов, будь то стандарты интерфейса или более «мягкие» спецификации.
- У большинства руководителей проектов или их представителей на табличке есть много вещей, кроме FIG, и поэтому они часто обращают внимание только во время голосования, даже если тогда. Несколько голосов потерпели неудачу просто из-за отсутствия кворума, и многие обыденные административные задачи просто остались без решения, поскольку никто не знал, кто должен был их выполнять.
- Несмотря на то, что единый редактор обеспечивает четкую власть, этот человек не может быть единственным или лучшим авторитетом в теме данной спецификации. В идеальном случае, многие люди, непосредственно вовлеченные в спецификацию или затронутые ею, имели бы равное место за столом.
- Процесс все еще слишком непрозрачен для посторонних, и даже для некоторых инсайдеров. Иногда трудно сказать, где принять участие в данной спецификации, так как нет никакой последовательности.
- Правила членства по-прежнему привилегируют проект, руководит кем-то еще; В сообществе PHP работают десятки умных, опытных разработчиков, которым было бы полезно поработать над спецификациями, но поскольку они не являются руководителями проектов или лейтенантами руководителей проектов, им никогда не разрешают голосовать.
- Несмотря на это, идея о том, что работа ФИЖ влияет только на проекты-участники, стала, как показано выше, почти комичной наивностью. Тем не менее, лишь немногие избранные приветствуются за столом.
В конце 2015 года ФИЖ добавила должность секретаря из 3 человек, избранную представителями проекта, для выполнения управленческих задач, но при этом не выполнять технические задачи. Я лично чувствую, что изменения имели оглушительный успех, поскольку задачи управления фактически выполняются сейчас, и секретари смогли помочь стандартизировать и формализовать большую часть необходимой документации при создании спецификаций. (Это нечто большее, чем просто немного поговорить!) Тем не менее, фиг не является полным.
Это достигло апогея в декабре 2015 года и в январе, когда в нескольких темах обсуждались различные недостатки ФПГ. В середине декабря я попытался объединить их в более широкое представление о « состоянии ФИГ », которое породило длительный, но живой разговор, в основном с согласием по проблемам. Это включало обсуждение процесса, которому следовали другие органы по стандартизации, включая ISO и IETF . Это, в свою очередь, побудило меня опубликовать в середине января концепцию предложения, вдохновленную IETF, которую я назвал «FIG 3.0». (ФИГ.2 — модель «Редактор / Координатор / Спонсор» с 2013 года, ФИГ.1 — общая доступность для всех до этого.) Я призываю всех, кто интересуется предметом, прочитать хотя бы начало этих тем для фона.
Предложение получило широкое одобрение, хотя и не всегда. Поэтому я приступил к превращению мозговых свалок в более формальные изменения в уставе с большой помощью Майкла Каллума, который был опубликован в списке в апреле.
ФИГ 3.0
Полное предложение доступно для просмотра в запросе на извлечение , и Майкл написал очень хорошее резюме его основных изменений. Я кратко изложу их здесь.
Во-первых, и что наиболее важно, он добавляет формулировку миссии для реальных целей на фиг:
Группа по взаимодействию PHP Framework (PHP FIG) нацелена на продвижение экосистемы PHP и продвижение хороших стандартов путем объединения проектов и людей для совместной работы. Он разрабатывает и публикует стандарты, опираясь на реальный опыт, а также исследования и эксперименты для себя и других, чтобы сформировать Стандартные рекомендации PHP (PSR).
Это на самом деле не новая концепция. В письменном виде он формализует то, что FIG уже делает и поддерживало в течение некоторого времени, и поддерживается опросами, проведенными ранее.
Во-вторых, рабочие группы становятся больше с минимальным размером 5. Эти члены рабочей группы могут быть связаны с проектом или нет, но предназначены для тех, кто имеет прямое участие в данной спецификации. Авторы библиотек кэша, например, для библиотеки кэширования, или разработчики асинхронных библиотек для PSR на Promises. Эти непосредственно затронутые люди имеют четкое «место за столом» и голосование в самой Рабочей группе до утверждения PSR, даже если они не являются участниками проекта. Более того, окончательное голосование не может произойти до тех пор, пока не будет, по крайней мере, двух реализаций, демонстрирующих, что предложение является жизнеспособным и может быть принято кем-то. Это изменение получено непосредственно из IETF.
В-третьих, окончательное голосование по спецификации после того, как Рабочая группа закончит с ним, будет проведено избранным основным комитетом из 12 человек. Работа основного комитета состоит в том, чтобы поддерживать последовательность и превосходство во всей работе FIG, уравновешивать как устоявшиеся модели, так и перспективные разработки, а также выступать в качестве стороннего рецензента усилий Рабочей группы. Они могут быть представителями проекта или нет; Это еще больше расширяет участие ФИЖ в глазах многих экспертов по PHP, которые не являются руководителями проектов. Более того, они избираются не только представителями проекта, но и всеми, кто активно участвует в ФПГ; это включает всех членов Рабочей группы, которые могут быть или не быть представителями проекта.
Представители проекта должны быть вовлечены только в определенное время для голосования в Главном комитете и в тех случаях, когда их проект имеет отношение к рабочей группе, к которой они могут присоединиться. Если нет, то их молчание или невмешательство не влияют на кворум и не препятствуют развитию спецификации, которая в любом случае им не нужна.
Позиция секретаря остается практически неизменной; Основной комитет и секретари являются равноправными участниками, равными по отношению к различным частям фиг. Секретари сохраняют работу механизма, в то время как Основной комитет обеспечивает как технический надзор за рабочими группами, так и «взгляд со стороны» на конкретную спецификацию.
Я полагаю, что это решает большинство структурных проблем сегодня, создавая среду, в которой сообщество PHP может работать более эффективно и результативно на благо каждого.
Слишком провидец?
Хотя предложение с самого начала получило широкое одобрение, в последнее время оно встретило некоторую оппозицию. Основное возражение заключается в том, что он «слишком далек» от первоначальной цели ФИЖ, и поэтому его следует либо оставить, либо использовать в качестве основы для новой группы, возможно, при этом сам ФПГ будет закрыт в ответ. В частности, Пол Джонс неоднократно заявлял, что он против «основополагающего видения» ФИЖ, которое должно было исключительно стандартизировать существующую практику только для проектов-членов.
Однако «видение основания» группы стандартов PHP, по словам модератора первоначального совещания, на котором она была основана, было для закрытой группы без участия общественности. В то же время, влияние на новые, еще не созданные проекты, не являющиеся участниками, явно было целью:
Я был бы рад, если бы первый комментарий к сообщениям в блоге или списку рассылки с объявлением о новом коде был: «Вау, это здорово, но вы должны запустить его через phpcs».
Первый не тестовый пост в списке от Дэвида Коллие однозначно заявил:
Каждый проект может иметь определенные стандарты, которые могут расширяться и дополнительно определять, как эти стандарты должны использоваться, но целью является набор стандартов PHP, предоставляемых в качестве ресурса для всех разработчиков PHP .
(выделение добавлено) и
Был предложен централизованный модерируемый список рассылки для обсуждения стандартов кодирования PHP, который будет размещен на lists.php.net. Список должен иметь общедоступные архивы, и привилегии немодерируемого размещения будут предоставлены на выборах теми, кто имеет права размещения . Каждый крупный проект может иметь более одного участника, но каждый проект должен иметь только один голос в отношении стандартных решений и членства.
(выделение добавлено).
Только после обратной реакции, в первоначальном списке php-стандартов и в других местах, линия партии изменилась, чтобы быть «только для нас». Однако, если мы хотим посмотреть на видение основателя, вот оно: закрытый список, создающий стандарты «как ресурс для всех разработчиков PHP». И нигде в этих утверждениях нет претензии только на стандартизацию «того, что уже сделано» ,
Идея закрытого списка была заброшена очень рано. Линия «только для нас» была главным образом защитой от (действительных) обвинений в чрезмерной досягаемости. И не говоря уже о том, чтобы быть только назад.
Ясно, что утверждать, что видение «основателей» было сугубо ретроспективной, единственной для нас организацией, является ревизионистской историей.
Новая группа?
Несколько человек предложили, чтобы изменения на фиг.3 были приняты не фигурой, а недавно созданной организацией. Аргумент гласит, что работа ФИГ завершена, и новая группа сможет действовать без какой-либо кармы, накопленной ФИГ, хорошей или плохой. Мне кажется, это тоже странный аргумент.
На сегодня фиг не имеет миссии. Так как же это можно объявить «выполненным»? Там не определены критерии приемлемости! Самое близкое, что у нас есть, — это запись в FAQ на веб-сайте, в которой говорится, что FIG существует для того, чтобы «рассказать об общих чертах между нашими проектами и найти способы совместной работы». Учитывая количество PSR в какой-то стадии разработки сейчас, кажется, еще есть о чем поговорить.
Любая хорошая карма, созданная ФИГ за последние 7 лет, не является собственностью немногих избранных. Это результат крови и пота всех, кто работал над любой спецификацией, которая была принята и используется, как представителей проектов, так и нет, всех, кто обсуждал FIG на конференциях или в своих проектах, и всех, чей разработчик живет были улучшены работой ФИГ. Большинство из этих людей не были основателями группы. Фактически, большинство первоначальных основателей давно перестали быть активными в FIG.
И наоборот, любая плохая карма, созданная ФИГ, волшебным образом не исчезнет, если использовать новое имя для новой группы. Если это, очевидно, продолжение ФИГ (что для всех, кому это небезразлично), немногие хулители ФИГ собираются внезапно сбросить свою оппозицию. А тем, чья проблема связана не с ФИЖ, а с избранными членами ФИГ, будет важно только участие этих лиц.
Может ли новая организация работать? Пока ФИГ сама закрылась и публично заявила, что новая организация является ее преемницей, она, вероятно, могла бы. Однако это кажется чрезмерным количеством ригамаролы и политики только для защиты вымышленного «видения».
Худший вариант развития событий — создание новой группы, но ФИГ не закрывается. Тогда PHP получит два конкурирующих органа по стандартизации, что, скорее, не позволит создать орган по стандартизации.
Вывод
У ФИГ была бурная история, чтобы быть уверенным. Однако история имеет очень четкую траекторию: к более активному участию сообщества и к более надежной структуре поддержки такого участия. Его создание как «Группы стандартов PHP» включало в себя публично заявленные цели использования всем сообществом PHP. На практике иначе быть не может; Проекты PHP больше не являются островками, поэтому стандарты, принятые во многих проектах, в конечном итоге оказывают влияние практически на все проекты. Вся концепция взаимодействия не может быть успешной, если их примут только участники проекта «крутые дети».
Фиг.3 — следующий и важный шаг в этой эволюции. За последние 7 лет компания FIG зарекомендовала себя как де-факто Группа стандартов PHP. Пришло время для FIG принять эту реальность и помочь создать лучшую экосистему PHP для всех.