Большое спасибо Кэлу Эвансу , Нейту Абеле и Ларри Гарфилду за рецензирование этой статьи. Мы ценим наших замечательных рецензентов за постоянное совершенствование контента SitePoint!
( Раскрытие информации: я являюсь одним из основателей ФИЖ. Наряду с Нейтом Абелем я являюсь самым длинным непрерывно действующим участником голосования в группе. Я был основной движущей силой PSR-1, PSR-2 и PSR-4 Их широкое принятие во многом способствовало легитимности ФПГ. Я записан в качестве координатора или спонсора и в других ПРБ. Я помогал в создании некоторых уставов, которые гипотетически направляют членов группы, в том числе выдающуюся роль в написание самих правил голосования. Я был первым секретарем, и в настоящее время только временным запретом публикации сообщений в списке рассылки ФИГ. Я также был субъектом неудачной попытки удалить меня из группы. Я выступаю против ФИГ 3.0 предлагает воссоздать группу на месте.)
Альтернативные Фьючерсы
В своей статье «Прошлое, настоящее и будущее PHP-FIG» Ларри Гарфилд рассказывает о своих впечатлениях от FIG, начиная с его основания и заканчивая одним из возможных вариантов будущего. Я рекомендую вам прочитать его полностью, прежде чем продолжить.
Здесь я попытаюсь рассмотреть некоторые из ошибок и упущений в статье Ларри и предложить два других возможных варианта будущего для фиг.
PHP-FIG 3.0: слишком ревизионный?
В другом месте я говорил, что то, что я назвал «основополагающим» видением ФИЖ, заключалось в том, чтобы сосредоточиться на проектах-членах, найти общие черты между ними и систематизировать эти общие черты. Ларри осуждает мое утверждение как «ревизионистскую историю» и утверждает, что истинное намерение было в большей степени соответствовать тому, что я назвал «грандиозным» видением (то есть всеобъемлющей группой стандартов для всех программистов PHP, участвующих проектов или нет).
Чтобы поддержать свою позицию, Ларри цитирует заметку о встрече Бретта Бибера Дэвида Колалье .
Целью этой встречи была разработка набора общих стандартов, которые PHP-проекты могут стремиться принять.
Каждый проект может иметь определенные стандарты, которые могут расширяться и дополнительно определять, как эти стандарты должны использоваться, но целью является набор стандартов PHP, предоставляемых в качестве ресурса для всех разработчиков PHP.
Ларри также черпает из Трэвиса Свайсгуда что-то подобное. Я процитирую немного больше поста Трэвиса, чем Ларри:
Ниже мое видение. Это мое видение и только мое, но это то, откуда я иду. … Я бы хотел, чтобы официально утвержденный стандарт вышел из нашей работы. … Когда через год код публикуется для публичного использования, мне бы очень понравилось, если бы первый комментарий к сообщениям в блоге или сообщениям в списке рассылки, объявляющих о новом коде, был: «Вау, это здорово, но вы должны запустить его через phpcs».
Поначалу это кажется существенным доказательством утверждения Ларри. Однако следует помнить, что «цель, идущая на встречу» — это не то же самое, что «результат, исходящий от встречи».
Поэтому вполне может быть правдой, что некоторые участники имели в виду нечто большее, чем «грандиозное» видение, когда они впервые прибыли. Но, побывав на этой первоначальной встрече, я лично помню, что к концу было принято решение не следовать «великому» видению. Вместо этого он должен был принять более ограниченный подход «для членов группы».
Чтобы обеспечить больше поддержки, чем моя память о дискуссии, я отправляю следующее:
-
Сам Тревис говорит в том же посте, связанном выше: «Мы решили сформировать официальную группу наших проектов, чтобы контролировать создание этого стандарта и работать над улучшением, более широко применяемыми стандартами в наших проектах. «
-
Кэл Эванс, также присутствующий на встрече, представляет краткое изложение :
-
«Чтобы перефразировать цель этой группы, мы говорим:« Эй, мы все согласны с тем, что мы собираемся кодировать таким образом, и мы бы хотели, чтобы вы это сделали ».» (Значит ли это, что Ларри все-таки правильно понял? «Нет, Кэл исправляет себя в более позднем электронном письме , в котором говорится:« Это должно было быть прочитано: перефразируя цель этой группы, мы говорим: «Эй, мы все согласны, что мы собираемся кодировать таким образом ».)
-
В том же последнем электронном письме Кэл также говорит: «Эта группа не ставит себя выше всех остальных, говоря, что мы знаем лучше. Мы пытаемся найти общий язык между многими проектами, чтобы разработчики PHP по всему миру могли перемещаться между кодами в этих проектах и не приходиться каждый раз пересматривать стандарты. … Хотелось бы, чтобы стандарты, согласованные этой группой, были широко приняты сообществом PHP в целом, это не является целью группы ».
-
-
Мэтью Вейер О’Пинни говорит: «Мы представляем большое количество библиотек компонентов и сред с тысячами, если не миллионами пользователей. Мы представляем этих пользователей в этой группе. … В-третьих, эти стандарты не являются обязательными. Вы можете принять их или нет. Мы просто рекомендуем их, а также обязуемся, чтобы наши представительные проекты использовали их. … Во всяком случае, мы очень внимательно следим за сообществом и максимально вовлекаем их — через наши индивидуальные проекты. «
-
Нейт Абеле вспоминает о первоначальной встрече: «Смысл объединения стандартов, с которыми мы согласились, заключался в том, чтобы предоставить нашему сообществу коллективных пользователей некоторую видимость взаимодействия между нашими проектами и обеспечить путь вперед для других проектов, которые Мне нравится взаимодействовать с нашими ».
Нейт продолжает: «У каждого есть индивидуальный выбор, считают ли они эти стандарты полезными для них, но мы, как руководители проектов, решили использовать эти стандарты в нашем коде , поэтому, если вы планируете использовать какой-либо из наших проектов, вы все равно будете использовать стандарт, так что мы могли бы также быть откровенны с людьми о том, что это за стандарты, на тот случай, если другие найдут их полезными (что, по моему высокомерию, я собираюсь предположить, что если мы как это делают ведущие разработчики и видные члены сообщества, да, возможно, и другие).
(Весь акцент выше мой; орфографические и грамматические ошибки в кавычках как написаны.)
В отличие от утверждений Ларри, можно заметить, что с самого начала группа решила сосредоточиться на своих собственных членах. В то же время мы знали не только о том, что другие будут наблюдать и могут принять решение о нашей практике, но и о том, что группа может выступать только за своих членов, а не за кого-либо еще. То есть некоторые могут выбрать работу ФИЖ в качестве «образца для подражания»; но, к счастью, в ролевых моделях вы не должны быть такими же, как все остальные.
В заключение: хотя Ларри обвиняет меня в своей статье «защиты« вымышленного »видения», было бы точнее сказать, что я стараюсь уважать истинное основополагающее видение группы, с которым Ларри, похоже, не согласен ,
Рабочий процесс FIG 2.0
Кажется, Ларри считает, что новая модель рабочего процесса довольно успешна:
В соответствии с этой моделью [нового регламента рабочего процесса] группа прошла стандарт автозагрузки PSR-4, стандарт кэширования PSR-6 и стандарт обмена сообщениями HTTP PSR-7.
Рассказ Ларри здесь несколько вводит в заблуждение. Хотя правда, что PSR 4 и 6 были приняты после того, как был принят этот устав, эти PSR были переходными. PSR 4 и 6 начались до регламента рабочего процесса, увидели значительную работу, а затем были повторно приняты группой после того, как регламент рабочего процесса был введен около 2013 года.
На сегодняшний день было четыре PSR, которые начались и закончились до устава рабочего процесса, два PSR были выпущены, которые начались до устава и закончились после его учреждения, и только один, который начался и закончился после устава рабочего процесса:
-
Предварительный устав («РИС. 1.0») — PSR-0 (ноябрь 2010 г.) — PSR-1 (июнь 2012 г.) — PSR-2 (июнь 2012 г.) — PSR-3 (январь 2013 г.)
-
Переходный (начатый под 1.0, законченный под 2.0) — PSR-4 (декабрь 2013 г.) — PSR-6 (декабрь 2015 г.)
-
Пост-устав («ФИГ 2.0») — PSR-7 (май 2015 г.)
Таким образом, пока трудно показать, что регламент рабочего процесса является существенной помощью для производства готовых PSR.
Измерение воздействия ФПГ
Ларри пытается количественно измерить влияние FIG на всю территорию PHP:
Разные PSR, опубликованные FIG, конечно же, повлияли на сообщество PHP далеко за пределами нескольких проектов-участников. … По данным Packagist, регистратор PSR-3 был установлен более 37 миллионов раз. Для PSR-7 это около 11 миллионов.
Конечно, количество загрузок кажется хорошим целевым показателем, который количественно оценивает влияние пакета. Но вы должны быть осторожны, чтобы убедиться, что метрика измеряет то, что вы думаете, что делает. Подсчет «загрузок» может быть затруднен небольшим количеством очень популярных пакетов, которые используют пакет PSR. Кроме того, вводить цифры без контекста вводит в заблуждение; они всегда должны быть представлены в сравнении с чем-то другим.
Я предлагаю измененный способ измерения количества авторов, затронутых PSR: количество зависимых пакетов. Это скажет нам, сколько различных пакетов, независимо от их популярности загрузки, используют пакеты PSR. Это должно дать нам некоторое представление (хотя и несовершенное) о количестве разработчиков, которые интегрируют работу FIG в свою собственную работу.
Так как Ларри использовал Packagist, я тоже буду этим пользоваться. Вот «installs» (количество загрузок) и «зависимые» (количество Composer require s в других пакетах) для пакетов PSR, созданных FIG:
| Пакет PSR | Установлено | Зависимые |
|---|---|---|
| PSR / кэш | 0.8м | 165 |
| PSR / журнал | 38.0m | 1943 |
| PSR / HTTP-сообщение | 11,3 млн | 711 |
| (общее количество) | 50.1m | 2819 |
Итак: авторы 165 пакетов используют psr/cache , 1943 — psr/log , а 711 — psr/http-message .
Для сравнения, здесь представлены три не-PSR-пакета, происходящие за пределами фиг. (Они не случайно выбраны; они просто первые, которые пришли мне в голову.)
| Пакет без PSR | Установлено | Зависимые |
|---|---|---|
| Доктрина / DBAL | 21.1m | 1313 |
| nesbot / углерод | 15.9m | +792 |
| vlucas / phpdotenv | 9,9 млн | 711 |
| (общее количество) | 46.9m | 2816 |
Это означает, что авторы 1313 пакетов используют doctrine/dbal , 792 — nesbot/carbon , а 711 — vlucas/phpdotenv . Эти пакеты не являются результатом обсуждений фиг. Они существуют полностью вне процесса PSR. И все же они имеют сравнимое количество установок и почти одинаковую досягаемость (с точки зрения зависимостей) в более широком PHP-ландшафте.
Опять же, я рекомендую осторожность при интерпретации количества «иждивенцев». Там могут быть смешанные факторы, чтобы повлиять на результаты. Например, некоторые из пакетов, не относящихся к FIG, существуют дольше, чем пакеты FIG, поэтому, возможно, пакеты PSR наверстают упущенное в данное время. Или один автор может создать большое количество пакетов с одинаковыми зависимостями.
Но даже в этом случае это сравнение должно дать сторонникам «большой» паузы видения. Охват FIG на всё PHP-сообщество может быть не таким большим, как они думают. Попытка позиционировать FIG в качестве группы стандартов на всей территории PHP в свете этого сравнения кажется самонадеянной и тщеславной.
ФИЖ Источник легитимности
Ларри утверждает, что ФИЖ несет ответственность за соблюдение:
FIG фактически стал органом стандартизации для PHP. Потребовалось время, чтобы это заработало, но это было…
Пришло время для FIG принять эту реальность и помочь создать лучшую экосистему PHP для всех.
Возможно, фиг это стало видно, правильно или нет. Если это так, то любая легитимность, которую заработал ФИЖ, обусловлена тем, что он не является официальным органом по стандартизации. FIG уже помогла «построить лучшую экосистему PHP для всех» и сделала это, сконцентрировавшись на своих проектах-членах в соответствии с концепцией «основания».
Преимущества этой работы в рамках концепции «основания» были приняты во всей этой экосистеме косвенно и добровольно. Он сделал это, не будучи самостоятельно назначенным органом по стандартизации над всеми программистами PHP. Таким образом, утверждение о том, что формальное тело необходимо для достижения «лучшей экосистемы PHP», является неподдерживаемым утверждением.
Альтернатива 1: независимые группы взаимодействия
В своей статье Ларри делает несколько замечаний о том, как работает ФИГ, и кто над чем работает. Свои наблюдения там мне сложно обобщить.
Тем не менее, Майкл Каллум (другой автор предложения на фиг. 3.0) написал TL; DR на фиг. 3.0 , в котором содержится соответствующее резюме:
Каждый имеет равное право голоса на PSR FIG, независимо от их опыта или значимости проекта в проблемном пространстве PSR.
В ФПГ задействовано много умных, удивительных людей, которые не являются> представителями проекта.
Участникам проектов сложно заниматься всем, что происходит на ФИЖ
Существует постоянный вопрос о том, производит ли ФПГ PSR для проектов-членов или для более широкого сообщества; особенно когда более широкое сообщество уделяет ему столько внимания из-за его фактического статуса «органа по стандартизации php».
Что касается четвертого пункта, я надеюсь, что мой комментарий выше показал, что нет никаких сомнений в том, что PSR FIG предназначены главным образом для его проектов-членов; другие могут свободно принимать или игнорировать их по своему усмотрению.
Первые три пункта, тем не менее, все разрешимы путем поощрения *-interop групп , по *-interop контейнера-взаимодействия и асинхронного взаимодействия . Это позволило бы решить три верхние точки TLDR практически без изменений текущей структуры FIG:
-
Проект
*-interopконцентрируется на своей конкретной проблеме и может пригласить (или привлечь внимание) тех, кто обладает соответствующей экспертизой. И контейнерное взаимодействие, и асинхронное взаимодействие смогли успешно это сделать. -
Проект
*-interopне обязательно должен быть ограничен только представителями проекта. Это может принести любого, кого захочет, в соответствии с желаниями руководителей проекта. -
Заинтересованные стороны могут участвовать в
*-interopили даже*-interopпроектов*-interop, по своему усмотрению, выбирая собственный уровень участия.
Поощрение независимых групп взаимодействия решает все точки TLDR с меньшей бюрократией, меньшей централизацией, меньшей иерархией, меньшим количеством комитетов, большей гибкостью и большей открытостью. Это также дает некоторый уровень доказательства того, что предложение, выдвинутое группой по взаимодействию, действительно было принято в нескольких проектах и готово к признанию. Когда группа взаимодействия готова, она может прийти к ФИЖ (если пожелает) с хорошо проверенным предложением.
Однако поощрение независимых групп взаимодействия не решает неустановленную проблему «раннего престижа». То есть, создание независимой группы взаимодействия не дает вашей работе характер «стандарта для всей земли PHP», прежде чем кто-либо фактически использует вашу работу. Для некоторых сторонников фиг.3 я полагаю, что «ранний престиж» — это особенность, а не ошибка.
Альтернатива 2: расформировать фиг
Вторая альтернатива состоит в том, чтобы объявить, что ФИЖ, как первоначально предполагалось, больше не служит полезной цели и должен распадаться , возможно, чтобы освободить место для какой-либо другой организации.
Как член-основатель группы, я не предлагаю эту альтернативу слегка. Однако, это сделало бы признание нескольких реалий, как я обсуждаю в своих постах в блоге «FIG Follies» ( часть 2 и часть 3 ). Эти реалии таковы:
-
В настоящее время существуют два конкурирующих видения, конкурирующих в рамках FIG: одно, которое придерживается видения «основания», и другое, которое придерживается «великого» видения рис. 3.0 как тела стандартов для всей PHP-земли.
-
То, что за изменение проголосовали, не означает, что оно не может быть отменено позже. Как таковых, одних голосов будет недостаточно для урегулирования вопроса, поскольку проигравшая сторона будет в пределах своих прав продолжать настаивать на своем доводе. Проблема в мировоззрении.
-
Лучшее долгосрочное решение для одного набора держателей видения явным образом отказаться от своего видения и, возможно, также выйти из ФИГ. Однако ни один из держателей видения не желает уйти, поскольку легитимность и репутация ФПГ (как заработано в рамках концепции «основания») слишком велики, чтобы отказаться от активов.
Поэтому лучше распустить группу полностью. Это фактически означает, что разные держатели видения сдаются друг другу одновременно, а не продолжают свое соперничество за фиг.
При роспуске группы ФИЖ должен поручить свои активы архивариусу для поддержания PSR, веб-сайта и т. Д. В их текущем состоянии. Это оставляет фактический продуктивный выход ФИГ (т.е. PSR) доступным для потомков. Архивариус будет держать в секрете имя и учетные записи ФИЖ и защищать их от повторного использования. Архивариус может также объединить ошибки и несущественные изменения в существующих принятых PSR.
Расформирование также оставляет поле открытым для формирования другой группы. Если другая группа, связанная со стандартами, возникнет после расформирования ФПГ, то эта группа должна будет зарабатывать по-своему, со своими достижениями, под новым именем.
Более подробно об этой альтернативе я расскажу в своем посте FIG Follies Part 3 .
Вывод
Ларри недавно объявил голосование по предложению FIG 3.0 , что означает, что теперь оно находится в руках участников голосования FIG. Если это пройдет, вышеупомянутые две альтернативы больше не будут возможны.
По моему мнению, голосование за предложение означает, что официальное мнение ФИЖ о себе изменится с «мы думаем, что знаем, что лучше для нас », на «мы думаем, что знаем, что лучше для вас» . Я считаю, что это изменится для хуже.