perlpolicy

СОДЕРЖАНИЕ

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

НАЗВАНИЕ

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

ОПИСАНИЕ

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

УПРАВЛЕНИЕ

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

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

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

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

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

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

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

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

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

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

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

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

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

• Мы «официально» поддерживаем две последние серии стабильных релизов. 5.24.x и более ранние версии теперь не поддерживаются. Начиная с выпуска 5.30.0, мы «официально» прекратим поддержку Perl 5.26.x, кроме предоставления обновлений безопасности, как описано ниже.

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

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

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

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

• В качестве поставщика у вас может быть требование переносить исправления безопасности за пределы нашего 3-летнего обязательства по поддержке. Мы можем оказать вам ограниченную поддержку и консультации при этом, и по возможности попробуем применить эти исправления к соответствующим веткам технического обслуживания в git, хотя мы можем или не можем выбрать выпуск нумерованных версий или «официальных» исправлений. См. "SECURITY VULNERABILITY CONTACT INFORMATION" в perlsec для получения подробной информации о том, как начать этот процесс.

СОХРАНЕНИЕ ОБРАТНОЙ СОСТОЯТЕЛЬНОСТИ И УСТЕРЕНИЕ

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

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

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

По этому пути лежит безумие.

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

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

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

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

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