Skip to content

Заявление о миссии

Группа по взаимодействию с PHP Framework (PHPH FIG) стремится продвигать экосистему PHP и продвигать хорошие стандарты, объединяя проекты и людей для совместной работы. Он разрабатывает и публикует стандарты, основанные на реальном опыте, а также исследованиях и экспериментах, проведенных им самим и другими, для формирования стандартных рекомендаций PHP (PSR), рекомендаций по развитию PHP (PER) и вспомогательных ресурсов (AR).

Состав

Проекты участников

Проекты-члены PHP FIG — это известные общедоступные проекты PHP или важные заинтересованные организации PHP, которые проявили интерес к поддержке миссии и работы FIG. Проекты участников должны быть выпущенными проектами с известными производственными развертываниями, а не амбициозными проектами. Проекты-члены не обязаны реализовывать какие-либо конкретные ПРБ, хотя ожидается, что соответствующие ПРБ должным образом учтены.

Проект, который существует исключительно как расширение или плагин другого проекта, не соответствует требованиям. Однако проекты могут использовать код, библиотеки или платформы из других проектов без дисквалификации. В тех случаях, когда это различие неясно, представители проекта должны использовать все свои возможности для реализации духа этого пункта.

Заявка на членство от проекта должна включать действующего представителя проекта или члена основного комитета в качестве спонсора, имя предлагаемого представителя проекта, а также описание проекта и его отношение к ФИЖ. Заявка после размещения должна быть обсуждена не менее двух недель. По истечении этого периода спонсирующий Представитель может объявить голосование членства. Если он проходит, проект признается проектом-участником с указанным Представителем проекта. Если это не так, проект может повторно подать заявку в любое время, если спонсор все еще может быть найден.

Членский проект может выйти из PHP FIG в письменной форме через официальный общедоступный канал FIG. Как только такое заявление опубликовано и отставка подтверждена секретарем, PHP-проект немедленно перестает быть проектом участника.

Бывший участник проекта может повторно подать заявку на членство в любое время в будущем.

Представители проекта

Голоса всех проектов-участников подаются представителями проектов, уполномоченными на это проектом-участником. Каждый представитель проекта выбирается исключительно проектом-участником, и их выбор не подлежит утверждению PHP FIG. Представитель проекта может быть заменен Участником проекта, который он представляет, в любое время.

Членский проект не может иметь одновременно более одного Представителя проекта. Ни один человек не может представлять более одного проекта одновременно.

Представитель проекта может временно передать свое право голоса или право на участие в рабочей группе другому лицу, уполномоченному Проектом-участником, который он представляет. Текущий Представитель проекта должен уведомить PHP FIG об этом назначении, и в нем должно быть указано имя временного Представителя проекта и период времени, в течение которого его временное право голоса или право на участие будут оставаться в силе. Все права голоса автоматически возвращаются первоначальному Представителю проекта по истечении указанного периода времени.

Если, по мнению PHP FIG, Представитель проекта действует ненадлежащим образом и наносит ущерб способности PHP FIG выполнять свои задачи, любой член Ключевого комитета может объявить голосование об исключении, чтобы запросить замену Представителя проекта или исключить Участника проекта, если замена Представителя проекта невозможна. В этих случаях соответствующий член проекта/представитель проекта не может голосовать. Если членский проект исключен, он может повторно подать заявку на членство как минимум через год. Если за представителя проекта проголосовали за замену, он не может вернуться, чтобы представлять проект, который он представлял во время голосования, или любой другой проект на неопределенный срок.

Представитель проекта также может одновременно быть членом основного комитета, редактором PSR или членом рабочей группы, но не секретарем.

Основной комитет

Основной комитет состоит из двенадцати (12) членов, признанных за их технические навыки и опыт. Основной комитет несет ответственность за окончательные решения относительно того, какие спецификации будут рассмотрены ФИЖ, а какие утверждены. Основной комитет отвечает за обеспечение высокого уровня качества и согласованности всех опубликованных спецификаций, а также за то, чтобы все соответствующие точки зрения и варианты использования были должным образом учтены.

Членам основного комитета не разрешается также быть секретарем. Представителю проекта разрешено, но не обязательно, также быть членом Основного комитета, однако ожидается, что члены Основного комитета будут учитывать влияние своих действий на экосистему PHP в целом, когда действуют в качестве члена Основного комитета.

Ожидается, что члены основного комитета будут проявлять активный интерес ко всем темам, выносимым на рассмотрение ФИЖ.

Секретари

Основная обязанность Секретаря ФИЖ состоит в том, чтобы выполнять функции беспристрастного администратора ФИЖ. Они служат в проектах членов и основном комитете, но действуют как независимые и беспристрастные судьи. Секретари ФИЖ также представляют ФИЖ в целом перед обществом и общественностью по вопросам, касающимся деятельности ФИЖ.

Хотя ниже приведен ряд определенных функций, они также должны выполнять другие обязанности по мере необходимости. Поскольку роль имеет преемственность (в том смысле, что всегда будет занимающий должность) и избыточность (есть несколько занимающих посты в случае отсутствия одного), можно гарантировать, что обязанности, возложенные на секретаря, всегда будут выполняться, и поэтому административные обязанности, такие как управление голосованием, всегда должны возлагаться на секретаря ФИЖ.

Ожидается, что все секретари ФИЖ будут оставаться беспристрастными и профессиональными, когда действуют в официальном качестве Секретаря, а также должны осознавать, что даже когда они не действуют в официальном качестве, их действия отражаются на PHP FIG, и ФИЖ не должна наносить дурную славу.

В целях обеспечения беспристрастности секретари не могут одновременно выполнять функции представителя проекта, члена основного комитета или редактора PSR. Однако они могут быть членами рабочей группы. Секретари также должны публично заявлять обо всех конфликтах интересов, например, если они участвуют в рабочей группе или являются членами основной команды членского проекта.

Определенные функции

Существует ряд определенных функций, которые должны выполнять секретари ФИЖ, но они также могут, в рамках своих полномочий, определенных вышеописанной всеобъемлющей ролью, выполнять другие обязанности по мере необходимости.

  • Управление сайтом
  • Организация GitHub и администрирование репозитория
  • Подсчет голосов и управление системой голосования
  • Отслеживание активности участников проекта
  • Обеспечение соблюдения устава
  • Разъяснение любого толкования текста устава при условии отсутствия возражений со стороны членов основного комитета и представителей проекта**
  • Обеспечьте, чтобы соответствующие маркетинговые средства (например, Twitter и Facebook) оставались профессиональными, актуальными и беспристрастными.
  • Умеренные обсуждения на github, в списке рассылки, каналах IRC и других официальных средствах связи, чтобы обеспечить поддержание соответствующей среды. Это включает в себя возможность ограничивать публикации и налагать запреты, за исключением того, что они не могут навсегда заблокировать или ограничить члена основного комитета или представителя проекта.
  • Если на конференции или другом специальном собрании проводится собрание ФИЖ, любой присутствующий секретарь должен делать заметки, чтобы сообщить об этом в список рассылки.
  • Действуя на протяжении всего своего срока в основном как защитники разработчиков для PHP FIG

** Если какое-либо разъяснение устава оспаривается или против него возражают три или более представителей проекта или членов основного комитета, оно должно быть поставлено на голосование. Если между секретарями не может быть достигнут консенсус по разъяснению, оно должно быть поставлено на полное голосование.

Доступ и возможности

Секретарям FIG будет предоставлен доступ к организации GitHub в качестве «Владельцев» и полный (административный) доступ ко всему, что касается официального веб-сайта, маркетинговых и коммуникационных средств, включая, помимо прочего, домен, Twitter, IRC-канал, пакеты packagist.org и список рассылки, чтобы они могли выполнять свои обязанности и обеспечивать управление средствами FIG представителями, избранными PHP FIG.

Кроме того, хотя они сами не являются полноправными членами, они могут начать любое голосование, но не подавать никаких голосов. Однако следует отметить, что любое голосование, начатое одним секретарем ФИЖ, должно управляться и подсчитываться другим секретарем для обеспечения беспристрастности.

Рабочие группы

Большая часть работы PHP FIG осуществляется рабочими группами под руководством и при поддержке основного комитета. Ожидается, что члены рабочей группы будут активно участвовать в работе рабочей группы.

У каждой рабочей группы есть единственный редактор, который отвечает за бесперебойную работу рабочей группы и имеет окончательные полномочия в отношении результатов группы. Редакторы назначаются Основным комитетом. Редакторы несут ответственность за управление развитием усилий Рабочей группы; для представления Рабочей группы в обсуждениях с остальной частью PHP FIG; для координации других участников; и для работы с другими членами Рабочей группы и Ключевого комитета по мере необходимости, чтобы увидеть усилия через соответствующий процесс. Любое лицо может быть редактором, если оно не является также секретарем. Если редактор предложения отсутствует без уведомления более 45 дней, Основной комитет может согласовать нового редактора. Редактор является окончательным авторитетом в отношении результатов работы рабочей группы, если не указано иное.

Представители широкой общественности могут подать заявку на вступление в рабочую группу в любое время, при условии одобрения редактором, по их мнению, опыт и точка зрения заявителя будут особенно ценны для развития

усилия Рабочей группы. Член Рабочей группы может быть удален в любое время Редактором, если, по его мнению, это лицо стало неактивным в течение более 30 дней или если это лицо мешает нормальному функционированию Рабочей группы.

Представители проекта или доверенное лицо, которое они укажут, могут подать заявку на вступление в Рабочую группу в любое время, если Редактор не возражает против этого, если, по их мнению, заявитель не имеет большого значения для предложения процесса и/или будет мешать нормальному функционированию Рабочей группы.

Одно лицо может быть редактором более чем одной рабочей группы одновременно.

Полная рабочая группа

Полная рабочая группа состоит из редактора, спонсора и как минимум трех других лиц. Спонсор должен быть членом основного комитета. В полной рабочей группе редактор и спонсор разделяют обязанности по управлению членством.

Физическое лицо может быть Спонсором более чем одной Рабочей группы одновременно.

При желании в состав рабочей группы также могут входить несколько других членов Основного комитета.

Ограниченная рабочая группа

Ограниченная рабочая группа состоит из редактора и как минимум двух других лиц. Спонсор не требуется. Любое лицо может быть редактором или членом ограниченной рабочей группы, за исключением того, что редактор не может быть также секретарем.

Управление рабочей группой

Рабочие группы создаются вступительным голосованием Основного комитета. Вступительное голосование включает в себя назначение редактора и, если применимо, спонсора.

Редактор и, если применимо, Спонсор могут в любое время уведомить Основной комитет о том, что задача данной Рабочей группы выполнена. В этот момент Рабочая группа распускается путем неявного одобрения. При необходимости может быть проведено голосование по решению о назначении нового редактора.

Редактор или спонсор рабочей группы может уйти в отставку в любое время, сообщив об этом Основному комитету через список рассылки. Если уходящее лицо укажет на предполагаемую замену членства в Рабочей группе, это лицо немедленно примет на себя вакантную роль после неявного одобрения. При необходимости голосование по решению о назначении нового редактора или спонсора может быть проведено после соответствующего периода выдвижения кандидатур.

Если рабочей группе не хватает редактора в течение 60 дней; не иметь Спонсора в течение 60 дней; иметь недостаточно активных членов в течение 60 дней; или не проявляет признаков активности в течение шести месяцев, тогда Основной комитет может провести голосование по решению, чтобы назначить нового редактора или спонсора после соответствующего процесса выдвижения кандидатур. Одним из вариантов этого голосования по решению должен быть роспуск Рабочей группы. Если не удается найти подходящих кандидатов в редакторы или спонсоры, рабочая группа автоматически распускается.

Если рабочая группа распущена, новая рабочая группа, охватывающая ту же сферу деятельности, может быть сформирована позднее путем нового голосования.

Секретари обеспечивают предоставление Рабочей группе необходимых ресурсов для поддержки их усилий, таких как выделенный репозиторий GitHub, список рассылки, чат или аналогичные инструменты.

Сопровождающие

Основной комитет несет полную ответственность за все артефакты, созданные PHP FIG. Однако в случае артефактов, которые должны изменяться с течением времени, Основной комитет может делегировать эту ответственность Сопровождающему за один или несколько связанных артефактов.

Развивающиеся артефакты следуют за семантическим управлением версиями. Если неясно, будет ли данное изменение считаться исправлением ошибки или второстепенным выпуском, Специалист по сопровождению будет считать второстепенным выпуском.

  • Для изменений, которые можно квалифицировать как выпуски исправлений ошибок, сопровождающий может выпустить новый выпуск артефакта в любое время.
  • Для изменений, которые можно квалифицировать как незначительные выпуски, Сопровождающий должен уведомить Основной комитет через сообщение в списке рассылки о намерении объединить данное изменение. Намерение слияния подлежит неявному одобрению с голосованием за одобрение, если это необходимо.
  • Для изменений, которые можно квалифицировать как основные выпуски, выпуск подлежит обязательному одобрению со стороны Основного комитета.

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

Сопровождающий данного артефакта назначается Главным комитетом голосованием. После создания данного артефакта Сопровождающий может уйти в отставку и назначить нового Сопровождающего в любое время с неявным одобрением. При необходимости голосование по решению о назначении нового Сопровождающего может быть проведено после соответствующего периода выдвижения кандидатур.

Секретари гарантируют, что у сопровождающего есть необходимый доступ и ресурсы для разработки артефакта, такие как доступ к репозиторию GitHub, списку рассылки, чату или подобным инструментам.

Артефакты

PHP FIG создает три основных формы выходных артефактов, которые подчиняются установленным рабочим процессам. Этот список не является исчерпывающим для действий или публикаций, которыми может заниматься PHP FIG.

  • Стандартная рекомендация PHP (PSR) определяет стандарт взаимодействия, который устанавливает «контракт» между поставщиками и потребителями. Т

Целью любого PSR является поощрение или облегчение межпроектного сотрудничества и стандартизации. PSR разрабатываются до определенного конечного состояния и после утверждения считаются замороженными во времени, чтобы обеспечить стабильную и надежную цель для разработчиков, за некоторыми исключениями, как указано в поправках к PSR и уставе PSR Evolution. ПРБ разрабатываются рабочей группой. * Рекомендация по развитию PHP (PER) — это формальное определение лучших практик, ссылок, руководств, универсальных инструментов или инструментов для их поддержки. Они могут развиваться со временем по мере развития языка PHP и экосистемы. PER разрабатываются рабочей группой. * Вспомогательные ресурсы (AR) — это дополнительные инструменты, библиотеки кода или примеры, относящиеся к PSR или PER или поддерживающие их. Примеры включают общие частичные реализации PSR или PER, реализации без операций или утилиты тестирования для реализаций PSR или PER. Все AR должны быть непосредственно связаны с одним или несколькими PSR или PER. AR разрабатывается сопровождающим.