perlpolicy

СОДЕРЖАНИЕ

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

НАЗВАНИЕ

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

ОПИСАНИЕ

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

УПРАВЛЕНИЕ

Perl 5 Портеры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

СОХРАНЕНИЕ ОБРАТНОЙ СОВМЕСТИМОСТИ И УСТАРЕВАНИЕ

Наше сообщество долгое время считало, что обратная совместимость является достоинством, даже если речь идёт о недостатке дизайна.

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

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

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

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

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

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

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

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

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

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

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

экспериментальный

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

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

устаревший

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

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

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

не рекомендуется

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

удален

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Необязательно проводить голосование по выбору perldelta записей, связанных с изменениями, которые уже были выбраны, а также для maint-pumpking не нужно получать голоса по изменениям, необходимым в 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 должна по-прежнему рассматриваться как работа первоначального автора. Все исправления, отчеты об ошибках и так далее должны передаваться им. Их направления развития должны уважаться по возможности.

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

• Версия модуля, распространяемого с Perl, по возможности должна быть последней версией модуля, распространяемой автором (последняя не-бета версия в случае общедоступных релизов Perl), хотя держатель pumpking может отложить обновление версии модуля, распространяемого с 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 на срок в один календарный месяц. Цель этого — предоставить возможность человеку изменить свое поведение.

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

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

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

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

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