perlpolicy

СОДЕРЖАНИЕ

• ИМЯ
• ОПИСАНИЕ
• УПРАВЛЕНИЕ
  • Разработчики Perl 5
• ТЕХНИЧЕСКОЕ ОБСЛУЖИВАНИЕ И ПОДДЕРЖКА
• СОХРАНЕНИЕ ОБРАТНОЙ СОВМЕСТИМОСТИ И УСТАРЕВШИЕ ЭЛЕМЕНТЫ
  • Терминология
• ВЕТВИ ТЕХНИЧЕСКОГО ОБСЛУЖИВАНИЯ
  • Внесение изменений в ветвь технического обслуживания
• ВНЕСЕННЫЕ МОДУЛИ
  • Социальный контракт об авторском контроле
• ДОКУМЕНТАЦИЯ
• СТАНДАРТЫ ПОВЕДЕНИЯ
• АВТОРСКИЕ ПРАВА

ИМЯ

perlpolicy - Различные политики и обязательства, связанные с ядром Perl

ОПИСАНИЕ

Этот документ является основным документом, в котором фиксируются все написанные политики относительно того, как разработчики Perl 5 коллективно разрабатывают и поддерживают ядро Perl.

УПРАВЛЕНИЕ

Разработчики Perl 5

Подписчики на perl5-porters (сами разработчики) бывают разных типов. Некоторые - это спокойные любопытные наблюдатели, которые редко участвуют и вместо этого следят за текущим развитием, чтобы быть в курсе новых изменений или функций в Perl. Некоторые представляют поставщиков, чтобы убедиться, что Perl продолжает компилироваться и работать на их платформах. Некоторые исправляют любые докладываемые ошибки, которые они могут исправить, некоторые активно исправляют свои любимые области (потоки, Win32, движок регулярных выражений), а другие, кажется, ничего не делают, кроме как жаловаться. Короче говоря, это ваш типичный набор технических специалистов.

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

Над этой группой разработчиков председательствует Ларри Уолл. Он имеет последнее слово о том, что изменяется и что не изменяется в любом из языков программирования Perl. В наши дни Ларри в основном занимается Raku, а Perl 5 курирует руководящий совет разработчиков, ответственный за решение того, что входит в каждый релиз и за обеспечение того, чтобы релизы происходили регулярно.

Ларри рассматривает разработку Perl по аналогии с правительством США: есть Законодательная власть (разработчики, представленные основной командой), Исполнительная власть (руководящий совет) и Верховный суд (Ларри). Законодательная власть может обсуждать и отправлять исправления в исполнительную власть, но исполнительная власть свободна отклонить их. Редко Верховный суд встанет на сторону исполнительной власти против законодательной власти или законодательной власти против исполнительной власти. В основном, однако, законодательная и исполнительная ветви власти должны ладить и улаживать свои разногласия без импичмента или судебных разбирательств.

Вы иногда можете увидеть ссылки на Правило 1 и Правило 2. Власть Ларри как Верховного судьи выражается в Правилах:

1. Ларри всегда по определению прав относительно того, как должен вести себя Perl. Это означает, что он имеет право на окончательное вето по основным функциям.

2. Ларри может изменить свое мнение по любому вопросу в последующие даты, независимо от того, использовал ли он ранее Правило 1.

Понятно? Ларри всегда прав, даже когда ошибался. Редко применяются оба правила, но они часто упоминаются.

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

ТЕХНИЧЕСКОЕ ОБСЛУЖИВАНИЕ И ПОДДЕРЖКА

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

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

Тем не менее, мы ценим стабильность и безопасность Perl и уже давно имеем негласный договор с более широким сообществом Perl о поддержке и обслуживании релизов Perl.

В данном документе кодифицированы обязательства по поддержке и техническому обслуживанию, которые сообщество Perl должно ожидать от разработчиков Perl:

• Мы «официально» поддерживаем две последних стабильные серии релизов. 5.30.x и более ранние версии больше не поддерживаются. По состоянию на выпуск 5.36.0 мы «официально» прекратим поддержку Perl 5.32.x, кроме предоставления обновлений безопасности, как описано ниже.

• По мере возможностей, мы будем пытаться исправлять критические проблемы в двух последних стабильных сериях релизов 5.x. Исправления для текущей серии релизов имеют приоритет над исправлениями для предыдущей серии релизов.

• По мере возможностей мы будем предоставлять «критические» исправления/релизы безопасности для любой основной версии Perl, релиз 5.x.0 которой произошел в течение последних трех лет. Мы можем гарантировать только предоставление этих исправлений для последнего выпуска .y в любой серии 5.x.y.

• Мы не будем предоставлять исправления безопасности или исправления ошибок для релизов разработки Perl.

• Мы рекомендуем поставщикам выпускать последнюю поддерживаемую версию Perl на момент заморозки кода.

• В качестве поставщика у вас может быть требование выполнить обратную портирование исправлений безопасности за пределами нашего трехлетнего обязательства по поддержке. Мы можем предоставить вам ограниченную поддержку и консультации при этом и, где возможно, постараемся применить эти исправления к соответствующим ветвям -maint в git, хотя мы можем или не можем выбрать создание пронумерованных релизов или «официальных» исправлений. См. "ИНФОРМАЦИЯ О КОНТАКТАХ ПО БЕЗОПАСНОСТИ И УЯВЛЯЕМОСТЯМ" в perlsec для получения подробностей о том, как начать этот процесс.

СОХРАНЕНИЕ ОБРАТНОЙ СОВМЕСТИМОСТИ И УСТАРЕВШИЕ ЭЛЕМЕНТЫ

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

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

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

Это путь к безумию.

Требование от конечных программистов изменить всего несколько конструкций языка, даже конструкции языка, которые ни один хорошо подготовленный разработчик никогда не будет использовать намеренно, равносильно тому, чтобы сказать: «вы не должны переходить на новую версию Perl, если у вас нет на 100% покрытия тестами и вы не можете полностью проанализировать свой код вручную». Если у нас будут инструменты, способные надежно обновлять исходный код Perl из одной версии Perl в другую, эти проблемы можно значительно уменьшить.

Мы хотим, чтобы Perl продолжал расти и процветать в ближайшие годы и десятилетия, но не за счет нашего сообщества пользователей.

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

Использование лексического псевдонима для включения или отключения устаревшего поведения следует рассматривать при необходимости, а в отсутствие псевдонима устаревшее поведение следует включать. То, какие несовместимые с обратной совместимостью изменения контролируются неявно 'use v5.x.y', должно решаться руководящим советом в консультации с сообществом.

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

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

Терминология

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

experimental

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

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

deprecated

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

Начиная с Perl 5.12, устаревшие функции и модули предупреждают пользователя при их использовании. Когда модуль устаревает, он также будет доступен на CPAN. Установка его с CPAN устранит предупреждения об устаревании для данного модуля.

Если вы используете устаревшую функцию или модуль и считаете, что его удаление из ядра Perl было бы ошибкой, свяжитесь с почтовой рассылкой perl5-porters и изложите свою позицию. Мы не устареваем вещи без веской причины, но иногда есть контр-аргумент, о котором мы не подумали. Исторически мы не различали функции «устаревшие» и «не рекомендуемые».

discouraged

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

removed

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

ВЕТВИ ПОДДЕРЖКИ

Новые релизы веток поддержки должны содержать только изменения, которые попадают в одну из «допустимых» категорий, указанных ниже, но не должны содержать никаких изменений, которые попадают в одну из «недопустимых» категорий. (Например, исправление ошибки, приведшей к сбою, не должно включаться, если оно нарушает бинарную совместимость.)

Не обязательно включать каждое изменение, соответствующее этим критериям, и, как правило, основное внимание должно уделяться решению проблем безопасности, ошибок, приведших к сбою, регрессий и серьезных проблем с установкой. Следует избегать соблазна включения множества незначительных изменений, которые не влияют на установку или выполнение perl (например, исправления орфографических ошибок в документации), чтобы уменьшить общий риск упустить что-то. Цель состоит в том, чтобы создавать релизы поддержки, которые являются ценными и в которых пользователи могут полностью доверять стабильности. (Дополнительная задача — избежать выгорания менеджера релиза поддержки или перегрузки других коммитеров, голосующих за изменения, которые нужно включить (см. "Получение изменений в ветвь поддержки" ниже).)

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

• Исправления, которые устраняют уязвимости CVE или проблемы безопасности. Эти изменения должны проходить через механизм отслеживания безопасности, а не применяться непосредственно; см. "SECURITY VULNERABILITY CONTACT INFORMATION" в perlsec.

• Исправления, которые устраняют ошибки, приведшие к сбою, ошибки утверждения и ошибки повреждения памяти, но не изменяют функциональность perl или негативно не влияют на производительность.

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

• Исправления, которые устраняют ошибки в функциях, которые были новыми в соответствующем стабильном выпуске 5.x.0.

• Исправления, которые исправляют все, что препятствует или серьезно влияет на создание или установку perl.

• Исправления проблем с переносимостью, такие как изменения в Configure и файлах в папке hints/.

• Минимальные исправления, которые устраняют ошибки тестирования, специфичные для платформы.

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

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

Следующие типы изменений НЕ приемлемы:

• Исправления, которые нарушают бинарную совместимость. (Пожалуйста, обратитесь в совет по управлению.)

• Исправления, которые добавляют или удаляют функции.

• Исправления, которые добавляют новые предупреждения или ошибки или устаревают функции.

• Портирование Perl на новую платформу, архитектуру или выпуск ОС, которое включает изменения в реализации.

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

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

Получение изменений в ветвь поддержки

Исторически только менеджер проекта выполнял выборку изменений из bleadperl в maintperl. Это вызывает проблемы масштабирования. В то же время ветви поддержки стабильных версий Perl требуют особого отношения. В связи с этим, начиная с Perl 5.12, у нас есть новый процесс для веток поддержки.

Любой коммитер может выполнить выборку любого коммита из blead во вспомогательную ветвь, предварительно добавив запись в соответствующий файл голосования во вспомогательной ветви maint-votes, объявив коммит как кандидата на обратный порт, а затем дождаться, пока не менее двух других коммитеров добавят свои голоса в поддержку этого (т. е. требуется как минимум три голоса, прежде чем коммит можно будет перенести обратно).

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

Вместо этого могут использоваться и другие механизмы голосования (например, отправка письма на perl5-porters и как минимум два других коммитера, отвечающие на список, давая свое согласие), при условии, что одинаковое количество голосов будет собрано прозрачным способом. В частности, предложения по выбору изменений должны быть видны всем на perl5-porters, чтобы мнения всех заинтересованных могли быть услышаны.

Нет необходимости проводить голосование по выбору perldelta-записей, связанных с изменениями, которые уже были выбраны, а также нет необходимости менеджеру выпуска поддержки получать голоса по изменениям, требуемым руководством Porting/release_managers_guide.pod, где такие изменения могут быть применены путем выборки из blead.

ВНЕСЕННЫЕ МОДУЛИ

Социальный договор об авторском контроле

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

Это заявление не является юридическим контрактом. Это заявление никоим образом не является юридическим документом. Perl распространяется по лицензии GNU Public License и по лицензии Artistic License; это точные юридические условия. Это заявление не касается права или лицензий. Это о сообществе, взаимном уважении, доверии и добросовестном сотрудничестве.

Мы признаем, что ядро Perl, определяемое как программное обеспечение, распространяемое с ядром самого Perl, является совместным проектом со стороны всех нас. Время от времени скрипт, модуль или набор модулей (далее именуемые просто «модулем») окажется настолько полезным и/или настолько важным для правильного функционирования самого Perl, что его следует распространять вместе с ядром Perl. Это никогда не должно делаться без явного согласия автора и ясного понимания со всех сторон, что это означает, что модуль распространяется на тех же условиях, что и сам Perl. Автор модуля должен понимать, что включение модуля в ядро Perl неизбежно означает некоторую потерю контроля над ним, так как время от времени могут потребоваться изменения в короткие сроки или для согласованности с остальной частью Perl.

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

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

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

• Версия модуля, распространяемого с Perl, должна по возможности соответствовать последней версии модуля, распространяемого автором (последняя версия без бета-тестирования в случае общедоступных релизов Perl), хотя совет по управлению может отложить обновление версии модуля, распространяемого с Perl, до последней версии до тех пор, пока последняя версия не пройдет достаточное тестирование.

Другими словами, автор модуля должен иметь последнее слово по модификациям своего модуля, когда это возможно (с учетом того, что ожидается, что все участники будут работать вместе и придут к разумным компромиссам в случае разногласий).

В крайнем случае:

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

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

При работе со вкладами модулей все, кто поддерживает Perl, должны помнить, что код принадлежит первоначальному автору, что он может не быть на perl5-porters в любой момент времени, и что патч не является официальным, пока он не был интегрирован в копию модуля автором. Для облегчения этого и пунктов №1, №2 и №3 выше, контактная информация авторов всех вкладов модулей должна храниться вместе с дистрибутивом Perl.

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

ДОКУМЕНТАЦИЯ

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

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

Примеры в документации должны иллюстрировать концепцию, которую они объясняют. Иногда лучший способ показать, как работает языковая функция, - это небольшая программа, которую читатель может запустить без изменений. Чаще примеры будут состоять из фрагмента кода, содержащего только «важные» части. Определение «важного» варьируется от фрагмента к фрагменту. Иногда важно объявить use strict и use warnings, инициализировать все переменные и полностью обрабатывать все условия ошибок. Однако чаще всего эти вещи затеняют урок, который пример был предназначен для преподания.

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

В общем, документация должна описывать, что Perl делает «сейчас», а не то, что он делал раньше. Совершенно нормально включать в документацию примечания о том, как изменилось поведение по сравнению с предыдущими выпусками, но, за очень немногими исключениями, документация не «двойная» — ей не нужно полностью описывать, как работали все старые версии.

СТАНДАРТЫ ПОВЕДЕНИЯ

Официальным форумом для разработки perl является рассылка perl5-porters, упомянутая выше, и её система отслеживания ошибок на GitHub. Отправка сообщений на форум и в систему отслеживания ошибок не является правом: от всех участников обсуждения ожидается соблюдение стандарта поведения.

• Всегда ведите себя вежливо.

• Следуйте инструкциям модераторов.

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

Хотя вежливость обязательна, доброта поощряется; если у вас есть сомнения, вежливы ли вы, просто спросите себя: «Я вежлив?» и стремитесь к этому.

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

Неприемлемое поведение повлечет за собой публичное и чётко обозначенное предупреждение. Второй случай неприемлемого поведения от того же лица повлечёт за собой удаление с форума и системы отслеживания ошибок на GitHub на один календарный месяц. Целью этого является предоставление человеку возможности изменить свой способ поведения.

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

Удаления, как и предупреждения, публичны.

Список модераторов будет общедоступен. В настоящее время это: Karen Etheridge, Neil Bowers, Nicholas Clark, Ricardo Signes, Todd Rinaldo.

АВТОРСКИЕ ПРАВА

«Социальный договор об авторских модулях» первоначально написан Russ Allbery <rra@stanford.edu> и perl5-porters.