perlpolicy

СОДЕРЖАНИЕ

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

НАЗВАНИЕ

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

ОПИСАНИЕ

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

УПРАВЛЕНИЕ

Разработчики 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.26.x и более ранние версии теперь не поддерживаются. Начиная с выпуска 5.32.0, мы «официально» прекратим поддержку Perl 5.28.x, за исключением предоставления обновлений безопасности, как описано ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

experimental

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

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

deprecated

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

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

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

discouraged

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

removed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ВНЕШНИЕ МОДУЛИ

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

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

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

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

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

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

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

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