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, хотя мы можем или не можем сделать доступными нумерованные релизы или «официальные» исправления. См. "SECURITY VULNERABILITY CONTACT INFORMATION" в perlsec для получения подробностей о том, как начать этот процесс.

ОБРАТНАЯ СОСТОЯТЕЛЬНОСТЬ И УСТРАНЕНИЕ ИЗ ИСПОЛЬЗОВАНИЯ

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

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

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

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

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

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

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

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

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

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

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

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

experimental

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

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

deprecated

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

Начиная с 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 на новую платформу, архитектуру или релиз ОС, предполагающий изменения в реализации.

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

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

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

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

Любой разработчик может выбрать любой коммит из 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), хотя управляющий совет может отложить обновление версии модуля, распространяемого с 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.