perlpolicy

СОДЕРЖАНИЕ

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

НАЗВАНИЕ

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

ОПИСАНИЕ

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

УПРАВЛЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

• Мы «официально» поддерживаем две последних серии стабильных релизов. 5.22.x и более ранние версии теперь не поддерживаются. С момента выхода 5.28.0 мы «официально» прекращаем поддержку Perl 5.24.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, и если затронутый код можно легко обновить, чтобы он продолжал работать, их можно рассмотреть для удаления. В случае сомнений осторожность диктует, что мы будем отдавать предпочтение обратной совместимости. Когда функция устаревает, будет опубликовано обоснование принятия решения, а ссылка на него будет предоставлена в соответствующих документах 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 (например, исправления орфографических ошибок в документации), чтобы снизить общий риск упустить что-либо. Цель заключается в создании релизов поддержки, которые являются ценными и в которых пользователи могут полностью доверять стабильности.

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

• Исправления уязвимостей или проблем безопасности. Эти изменения следует применять с помощью механизма отслеживания проблем безопасности, а не непосредственно; см. "ИНФОРМАЦИЯ О КОНТАКТАХ ПО ПРОБЛЕМАМ БЕЗОПАСНОСТИ" в perlsec.

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

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

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

• Исправления всего, что препятствует или серьезно затрудняет сборку или установку Perl.

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

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

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

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

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

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

• Изменения, добавляющие или удаляющие функции.

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

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

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

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

Внесение изменений в ветку поддержки

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

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

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

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

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

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

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

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

Данное утверждение не является юридическим соглашением. Это утверждение никоим образом не является юридическим документом. Perl распространяется по GNU Общественной Лицензии и по Художественной Лицензии; именно эти юридические условия имеют значение. Это утверждение не касается права или лицензий. Это вопрос сообщества, взаимного уважения, доверия и добросовестного сотрудничества.

Мы признаем, что ядро 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, упомянутая выше, и ее система отслеживания ошибок в rt.perl.org. Публикация в списке рассылки и системе отслеживания ошибок не является правом: ожидается, что все участники обсуждения будут соблюдать стандарт поведения.

• Всегда будьте вежливы.

• Учитывайте модераторов.

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

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

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

Неприемлемое поведение приведет к публичному и четко определенному предупреждению. Второй случай неприемлемого поведения от одного и того же лица приведет к удалению из списка рассылки и rt.perl.org на срок в один календарный месяц. Цель этого — дать человеку возможность изменить свое поведение.

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

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

Список модераторов будет общедоступным. В настоящее время это: Aaron Crane, Andy Dougherty, Karen Etheridge, Ricardo Signes, Sawyer X, Steffen Müller, Todd Rinaldo.

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

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