Рабочий процесс рекомендаций по стандартам PHP (PHP PSR)

Предварительный проект

Цель этапа предварительного проекта - определить, заинтересовано ли большинство PHP FIG в публикации PSR для предлагаемой концепции.

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

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

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

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

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

Рабочая группа может продолжить работу над предложением в течение всего периода голосования.

Черновик

Целью этапа проекта является обсуждение и доработка предложения PSR до момента, когда оно может быть рассмотрено на рассмотрение Основным комитетом FIG.

На стадии черновика члены рабочей группы могут вносить любые изменения, которые они считают нужными, с помощью запросов на вытягивание, комментариев на GitHub, цепочек рассылки, чата и аналогичных инструментов. Изменения здесь не ограничиваются какими-либо строгими правилами, и возможны фундаментальные переписывания, если они поддерживаются редактором. Альтернативные подходы могут быть предложены и обсуждены в любое время. Если редактор и спонсор убеждены, что альтернативное предложение превосходит первоначальное предложение, то альтернативное предложение может заменить оригинал. Ожидается, что члены рабочей группы будут продолжать работу на этапе разработки проекта. Обсуждения являются публичными, и любой, независимо от принадлежности к FIG, может внести конструктивный вклад. На этом этапе редактор имеет окончательную власть над изменениями, внесенными в предлагаемую спецификацию.

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

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

Если голосование проходит, предложение официально переходит на этап рассмотрения. В противном случае он остается в фазе черновика.

Обзор

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

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

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

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

Принятый

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

Исправления

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

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

Устарело

Устаревший PSR - это документ, который был утвержден, но больше не считается актуальным или рекомендованным. Обычно это происходит из-за того, что PSR заменяется новой версией, но это не обязательно.

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

Заброшенный

Заброшенный PSR - это тот, над которым активно не работают. Если рабочая группа по PSR будет распущена, PSR автоматически помечается как прекращенная.

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

Референдум по проекту

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