Perl 정책

Perl 정책 (perlpolicy)

Perl 코어와 관련된 각종 정책과 약속을 기록한 문서예요. Perl 5 Porters가 Perl 코어를 어떻게 공동으로 개발·유지하는지에 대한 모든 문서화된 정책을 담는 마스터 문서예요.

출처: Perl 공식 문서 - perlpolicy

본문

거버넌스 (GOVERNANCE)

Perl 5 Porters

perl5-porters(즉 포터들) 구독자는 여러 유형이에요. 어떤 이들은 조용하고 호기심 많은 lurkers로, 거의 참여하지 않고 진행 중인 개발을 지켜보며 Perl의 새 변경·기능을 미리 알기만 해요. 어떤 이들은 벤더 대표로, Perl이 자기 플랫폼에서 계속 컴파일되고 동작하도록 보장하는 역할을 해요. 어떤 이들은 고치는 법을 아는 보고된 버그를 패치하고, 어떤 이들은 자기 애정 분야(스레드, Win32, 정규식 엔진)를 적극적으로 패치하며, 어떤 이들은 불평만 하는 것처럼 보이기도 해요. 말하자면 기술인들의 흔한 혼합이에요.

이 사람들 사이에 핵심 Perl 팀(core Perl team) 이 있어요. Perl 언어와 인터프리터의 지속적인 개발에 참여하는 신뢰받는 자원봉사자들이에요. 언어 개발자나 커미터일 필요는 없어요.

이 포터 그룹 위에는 Larry Wall이 있어요. 그는 어떤 Perl 프로그래밍 언어에서 무엇이 바뀌고 바뀌지 않는지에 대한 최종 발언권을 가져요. 요즘 Larry는 대부분의 시간을 Raku에 쓰고 있고, Perl 5는 각 릴리스에 무엇이 들어갈지 결정하고 정기적으로 릴리스가 일어나도록 보장하는 포터들의 스티어링 카운슬(steering council) 이 이끌고 있어요.

Larry는 Perl 개발을 미국 정부에 비유해요. 입법부(코어 팀이 대표하는 포터들), 행정부(스티어링 카운슬), 대법원(Larry)이 있다는 거죠. 입법부는 행정부에 수정안을 논의하고 제출할 수 있지만, 행정부는 자유롭게 거부할 수 있어요. 드물게 대법원이 입법부보다 행정부 편을 들거나, 행정부보다 입법부 편을 들기도 해요. 하지만 대부분 입법부와 행정부는 탄핵이나 소송 없이 서로 잘 지내며 차이를 해결해야 해요.

가끔 Rule 1과 Rule 2에 대한 언급을 볼 수도 있어요. 대법원으로서 Larry의 권한은 The Rules에 표현돼 있어요:

Larry는 Perl이 어떻게 동작해야 하는지에 대해 정의상 항상 맞아요. 즉 코어 기능에 대한 최종 거부권을 갖는다는 뜻이에요.
Larry는 이전에 Rule 1을 발동했는지와 무관하게, 나중에 어떤 사안에 대해 마음을 바꿀 수 있어요.

이해됐나요? Larry는 틀렸을 때조차 항상 맞아요. 두 Rule이 실제로 행사되는 걸 보는 일은 드물지만, 자주 암시되곤 해요.

코어 팀과 스티어링 카운슬의 구성원이 어떻게 선출되거나 순환되는지의 구체 사항은 perlgov를 보세요. 자세히 풀어 설명돼 있어요.

버전 관리 (VERSIONING)

Perl은 5.X.Y 버전 번호 체계를 써요.

짝수 X 값(예: 5.40, 5.42)은 안정(stable) 릴리스 계열이에요.
홀수 X 값(예: 5.41, 5.43)은 다음 안정 릴리스로 이어지는 개발(development) 릴리스 계열이에요. 개발 릴리스는 대략 한 달마다 새 Y가 하나씩 증가해요.
안정 계열의 Y 증가(예: 5.42.1, 5.42.2)는 유지보수(maintenance) 릴리스로, 치명적 버그 수정과 보안 패치만 담아요.

새 안정 릴리스 계열은 보통 1년에 한 번 만들어져요.

유지보수와 지원 (MAINTENANCE AND SUPPORT)

Perl 5.42 릴리스 시점의 "공식적으로" 지원되는 Perl 버전은 다음과 같아요:

Version track    Start date      Support status
-------------    -----------     --------------
5.44.x           2026-Jul-15     Full support (current stable)
5.42.x           2025-Jul-03     Full support (previous stable)
5.40.x           2024-Jun-09     Security fixes only
[ Any older stable release ]     End of life

Perl은 기업 주체가 아니라 커뮤니티가 개발해요. Perl 코어에 기여된 모든 변경은 기부의 결과예요. 보통 이 기부는 커뮤니티 개별 구성원의 코드나 시간 기여예요. 가끔 특정 개인이나 프로젝트에 대한 기업·조직의 후원 형태로 오기도 해요.

자원봉사 조직으로서 우리가 하는 약속은 Perl에 기여할 의무가 없는 개인들의 선의와 노력에 크게 의존해요.

그렇긴 해도 우리는 Perl의 안정성과 보안을 소중히 여기고, 오랫동안 더 넓은 Perl 커뮤니티와 함께 Perl 릴리스를 지원·유지하겠다는 불문율(unwritten covenant)을 지켜 왔어요.

이 문서는 Perl 커뮤니티가 Perl 개발자들로부터 기대해야 할 지원·유지보수 약속을 명문화해요.

최선을 다해, 가장 최근의 두 안정 5.x 릴리스 계열의 치명적 문제를 고치려고 노력할 거예요. 현재 릴리스 계열에 대한 수정이 이전 릴리스 계열에 대한 수정보다 우선해요.
최선을 다해, 지난 3년 안에 5.x.0 릴리스가 나온 어떤 주요 버전의 Perl에 대해 "치명적" 보안 패치·릴리스를 제공할 거예요. 어떤 5.x.y 계열에서는 가장 최근 .y 릴리스에 대해서만 제공할 수 있어요.
Perl의 개발 릴리스에 대해서는 보안 업데이트나 버그 수정을 제공하지 않을 거예요.
벤더에게 코드 프리즈 시점의 가장 최근 지원 릴리스를 배포하도록 권장해요.
벤더 입장에서는 우리의 3년 지원 약속을 넘어 보안 수정을 백포팅해야 할 요구사항이 있을 수 있어요. 그렇게 할 때 제한적인 지원과 조언을 제공할 수 있고, 가능하면 git의 관련 -maint 브랜치에 그 패치를 적용하려고 노력할 거예요. 다만 번호가 매겨진 릴리스나 "공식" 패치를 만들지는 선택일 수 있어요. 그 과정을 시작하는 방법은 "SECURITY VULNERABILITY CONTACT INFORMATION" in perlsec를 보세요.

하위 호환성과 폐기 (BACKWARD COMPATIBILITY AND DEPRECATION)

우리 커뮤니티는 오래전부터 하위 호환성은 미덕이라고 믿어 왔어요. 비록 해당 기능이 설계 결함일지라도요.

우리 모두 지난 수십 년간 저지른 실수 일부를 되돌리고 싶어요. 우리가 만든 모든 설계 오류와 함께 사는 것은 고통스러운 정체를 낳을 수 있어요. 실수를 되감는 건 아주 아주 어려워요. 사용자에게 적극적으로 해를 끼치지 않고 되감는 것은 거의 불가능해요.

최근 들어 이전 Perl 버전과의 호환을 무시하거나 적극적으로 반대하는 게 유행이 됐어요. 때로는 이전에 다른 뜻을 가졌던 문법을 찬탈하려는 변경이 제안돼요. 때로는 이전에 터무니없던 시맨틱을 개선하려는 변경이 제안돼요.

이 길의 끝에는 광기가 있어요.

최종 사용자 프로그래머에게 몇 개의 언어 구조만 바꾸라고 요구하는 것은, 교육 잘 받은 개발자라면 의도적으로는 절대 쓰지 않을 언어 구조조차도, "100% 테스트 커버리지가 있고 코드베이스를 완전히 수동 감사할 수 없다면 Perl의 새 릴리스로 업그레이드하면 안 된다"고 말하는 것과 다름없어요. Perl 소스 코드를 한 버전에서 다른 버전으로 안정적으로 업그레이드할 수 있는 도구가 있었다면, 이 우려는 크게 완화될 수 있었어요.

우리는 Perl이 앞으로 수년·수십 년 동안 계속 성장하고 번성하기를 바라지만, 사용자 커뮤니티를 희생해서는 안 돼요.

기존 문법과 시맨틱은 매우 제한된 상황에서만 제거 대상으로 표시돼야 해요. 그것들이 아주 드물게 쓰이고, Perl 언어·인터프리터의 실제 개선을 가로막으며, 영향을 받는 코드를 계속 동작하게 쉽게 업데이트할 수 있다면 제거를 고려할 수 있어요. 의심스러울 때는 신중함이 하위 호환성을 선호하도록 해요. 기능이 deprecated되면 결정 과정을 설명하는 성명이 게시되고, 관련 perldelta 문서에 그 링크가 제공돼요.

적절할 때 어휘 프래그마(lexical pragma)로 레거시 동작을 켜거나 끄는 걸 고려해야 하고, 프래그마가 없으면 레거시 동작이 활성화되어야 해요. 어떤 하위 비호환 변경이 'use v5.x.y'로 암묵적으로 제어되는지는 스티어링 카운슬이 커뮤니티와 협의해 결정해야 하는 사안이에요.

역사적으로 우리는 하위 호환성보다 훨씬 더 높은 기준, 즉 버그 호환성(bugward-compatibility) 을 스스로에게 요구해 왔어요. 구현의 어떤 우연이든 어떤 코드를 실행하는 의도하지 않은 부수 효과든, 다른 어떤 기능과 같은 열의로 방어해야 할 언어의 기능으로 여겨졌어요. 우리가 Perl을 계속 개선하면서 이 의도하지 않은 기능들이 아무리 답답하더라도, 그것들은 종종 우리의 보호를 받을 자격이 있어요. Perl로 작성된 기존 소프트웨어가 계속 올바르게 동작하는 건 매우 중요해요. 최종 사용자 개발자가 버그를 기능으로 채택했다면, 우리도 그렇게 대우해야 해요.

기존 언어 구조와 문법을 깨지 않는 새 문법과 시맨틱은 기준이 훨씬 낮아요. 유용하고, 우아하고, 잘 설계되고, 잘 테스트되었다는 것만 증명하면 돼요. 대부분의 경우 이러한 추가는 한동안 _experimental_로 표시될 거예요. 자세한 건 아래를 보세요.

용어 (Terminology)

Perl 코어에서 기능을 제거하는 걸 논의할 때 같은 것을 말하고 있는지 확실히 하기 위해, 몇몇 단어·구절에 대해 구체적 정의가 있어요.

experimental

Perl 코어의 어떤 것이 experimental로 표시되면, 우리는 통보 없이 그 동작을 바꾸거나, deprecate하거나, 제거할 수 있어요. experimental 기능 사용자를 위한 전환 경로를 항상 최선을 다해 매끄럽게 하겠지만, 실험 기능이 유용하다고 생각하고 미래를 만드는 데 돕고 싶다면 perl5-porters 메일링 리스트에 연락해야 해요.

실험 기능은 비-실험으로 표시되기 전에 두 번의 안정 릴리스에서 실험적이어야 해요. 실험 기능은 설계 변경 버그가 더 이상 열려 있지 않고, 개발 주기 전체 동안 동작이 변하지 않았을 때만 실험 상태를 해제할 수 있어요. 즉 v5.20.0에 있던 기능은, 그 동작이 v5.21 전체 동안 변하지 않았을 경우에만 v5.22.0에서 더 이상 실험적이지 않다고 표시될 수 있어요.

deprecated

Perl 코어의 어떤 것이 deprecated로 표시되면, 우리는 미래에 코어에서 제거할 수도 있고 안 할 수도 있어요. 일반적으로 하위 비호환 변경은 제거되기 전 두 릴리스 주기 동안 deprecation 경고가 있지만, 위험이 아주 낮거나 이득이 아주 높으면 한 주기만에 제거될 수도 있어요.

Perl 5.12부터 deprecated 기능·모듈은 사용될 때 사용자에게 경고해요. 모듈이 deprecated되면 CPAN에서도 쓸 수 있게 돼요. CPAN에서 설치하면 그 모듈의 deprecation 경고가 조용해져요.

deprecated 기능·모듈을 쓰고 있는데 코어에서 제거하는 게 실수라고 생각한다면, perl5-porters 메일링 리스트에 연락해 자기 사연을 호소하세요. 우리는 이유 없이 deprecate하지 않지만, 때로는 고려하지 못한 반대 논거가 있을 수 있어요. 역사적으로 우리는 "deprecated"와 "discouraged" 기능을 구분하지 않았어요.

discouraged

때때로 우리는 실수라고 생각하는 언어 구조·기능을 discouraged로 표시할 수 있어요. discouraged 기능은 현재 제거 후보가 아니지만, Perl 코어에 대한 중대한 개선을 가로막는 것으로 밝혀지면 나중에 deprecate할 수 있어요.

removed

기능·구조·모듈이 deprecated로 표시된 후에는 Perl 코어에서 제거할 수 있어요. 놀랍지 않게, 이것들을 removed했다고 말해요. 모듈이 제거되면 더 이상 Perl과 함께 배포되지 않지만, CPAN에서는 계속 쓸 수 있어요.

유지보수 브랜치 (MAINTENANCE BRANCHES)

유지보수 브랜치의 새 릴리스는 아래에 제시된 "허용 가능한" 범주 중 하나에만 들어가는 변경을 담아야 하고, "허용 불가능한" 범주에 들어가는 변경은 절대 담으면 안 돼요. (예를 들어, 크래시 버그 수정이라도 바이너리 호환성을 깨면 포함되면 안 돼요.)

이 기준을 충족하는 모든 변경을 포함할 필요는 없고, 일반적으로 보안 문제, 크래시 버그, 회귀, 심각한 설치 문제를 다루는 데 초점을 맞춰야 해요. perl의 설치·실행에 영향을 주지 않는 사소한 변경(문서의 철자 수정 같은)을 잔뜩 포함하고 싶은 유혹은, 뭔가를 간과할 전체 위험을 줄이기 위해 저항해야 해요. 의도는 가치 있고 사용자가 안정성에 완전한 신뢰를 가질 수 있는 유지보수 릴리스를 만드는 거예요. (부차적 고려는 maint-release 관리자를 태우거나, 포함할 변경에 투표하는 다른 커미터들을 압도하지 않는 거예요. 아래 "Getting changes into a maint branch"를 보세요.)

다음 유형의 변경은 아래의 "허용 불가능한" 범주에 들어가지 않는 한 허용 가능한 것으로 간주될 수 있어요:

CVE나 보안 문제를 고치는 패치. 이러한 변경은 직접 적용하지 말고 보안 보고 메커니즘으로 전달해야 해요. "SECURITY VULNERABILITY CONTACT INFORMATION" in perlsec를 보세요.
크래시 버그, 어서션 실패, 메모리 손상을 고치지만 그 외에는 perl의 기능을 바꾸거나 성능에 부정적 영향을 주지 않는 패치.
이전 릴리스에 비해 perl 동작의 회귀를 고치는 패치. 회귀가 아무리 오래됐어도요. 어떤 사람들은 아주 오래된 perl 버전에서 최신 버전으로 업그레이드할 수 있기 때문이에요.
해당 5.x.0 안정 릴리스에서 새로 도입된 기능의 버그를 고치는 패치.
perl의 빌드·설치를 방해하거나 심각하게 방해하는 무언가를 고치는 패치.
Configure와 hints/ 폴더의 파일 변경 같은 이식성 수정.
플랫폼 특정 테스트 실패를 고치는 최소 패치.
사실 오류를 바로잡거나, 현재 구현의 중대한 버그·결함을 설명하거나, 깨진 마크업을 고치는 문서 업데이트.
dual-life 모듈 업데이트는 (위처럼) 크래시 버그나 보안 문제를 고치는 최소 패치로 구성되어야 해요. CPAN이 정본(canonical)인 dual-life 모듈에 대한 변경은 업스트림 저자와 조정해야 해요.

다음 유형의 변경은 허용 불가능해요:

바이너리 호환성을 깨는 패치. (스티어링 카운슬과 상의하세요.)
기능을 추가하거나 제거하는 패치.
새 경고·오류를 추가하거나 기능을 deprecate하는 패치.
구현 변경을 수반하는 새 플랫폼·아키텍처·OS 릴리스로의 Perl 포팅.
dual-life 모듈의 새 버전은 maint에 import하면 안 돼요. 그것들은 다음 안정 계열에 속해요.

주어진 패치가 maint 릴리스에 들어갈 만한지 의문이 있다면, 거의 확실히 포함하면 안 돼요.

변경을 maint 브랜치에 넣기 (Getting changes into a maint branch)

역사적으로 단 한 명의 프로젝트 관리자만 bleadperl에서 maintperl로 변경을 cherry-pick했어요. 이것은 확장성 문제가 있어요. 동시에 안정 Perl 버전의 유지보수 브랜치는 아주 신중하게 다뤄야 해요. 이를 위해 Perl 5.12부터 maint 브랜치에 대한 새 프로세스가 있어요.

어떤 커미터든 먼저 maint-votes 브랜치의 관련 투표 파일에 그 커밋을 백포팅 후보로 발표하는 항목을 추가하고, 다른 커미터 최소 두 명이 그걸 지지하는 투표를 추가하기를 기다린 뒤(즉 커밋이 백포팅되려면 최소 총 3표 필요), blead에서 maint 브랜치로 어떤 커밋이든 cherry-pick할 수 있어요.

적절한 후보 커밋 집합을 모으고 3표가 모인 커밋을 cherry-pick하는 작업의 대부분은 maint 브랜치 릴리스 관리자가 하지만, 특정 수정이 간과되지 않도록 하거나 이미 간과됐을까 봐 우려하는 다른 사람은 추가 제안을 자유롭게 할 수 있어요.

동일한 수의 표를 투명한 방식으로 모은다면 다른 투표 메커니즘을 대신 쓸 수도 있어요(예: perl5-porters에 메일을 보내고 다른 커미터 최소 두 명이 리스트에 동의를 답하는 것). 특히, 어떤 변경을 cherry-pick할지에 대한 제안은 perl5-porters의 모든 사람이 볼 수 있어야 해서 관심 있는 모든 사람의 의견을 들을 수 있어야 해요.

이미 cherry-pick된 변경과 관련된 perldelta 항목을 cherry-pick하는 데 투표를 할 필요는 없고, _Porting/release_managers_guide.pod_가 요구하는 변경으로서 blead에서 cherry-pick 수단으로 적용할 수 있는 변경에 대해 maint-release 관리자가 투표를 받을 필요도 없어요.

기여 모듈 (CONTRIBUTED MODULES)

다음은 예술적 통제(artistic control), 즉 패키지 저자가 자기 코드의 미래를 이끌고 자기 작업에 대한 통제를 유지하는 능력에 대한 성명이에요. 저자가 자기 작업에 대한 통제를 가져야 하고, 그 통제를 유지하도록 보장하는 것이 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 코어의 모듈 버전을 저자가 유지하는 버전에서 공식적으로 포크하기로 선택할 수 있어요. 이것은 가볍게 해서는 안 되고, 가능하다면 항상 Larry의 직접적인 의견을 들은 후에만 해야 해요. 이렇게 되면 Perl 코어와 함께 배포되는 모듈에 그것이 포크 버전이고, 원저자의 작업에 기반하지만 더 이상 그들이 유지하지 않는다는 사실을 명시적으로 만들어야 해요. 이것은 문서와 모듈 소스의 주석 양쪽 모두에 명시되어야 해요.

다시 말하지만, 이것은 최후의 수단이어야 해요. 이상적으로는 절대 일어나서는 안 되고, 이 일을 하기 전에 협력과 타협의 모든 가능한 노력을 기울여야 해요. Perl의 전반적 건강을 위해 모듈을 포크하는 게 정말 필요하다면, 원저자에게 영구히 적절한 공로를 인정해야 하고, 두 브랜치의 재병합이 앞으로 가능한지 보려고 그 결정을 계속 재평가해야 해요.

기여 모듈을 다룰 때, Perl을 유지하는 모든 사람은 코드가 원저자에게 속하고, 원저자가 특정 시점에 perl5-porters에 없을 수 있으며, 패치가 저자의 모듈 사본에 통합되기 전까지는 공식적이 아니라는 걸 명심해야 해요. 이것과 위 1,2,3번 항목을 돕기 위해 모든 기여 모듈의 저자 연락처를 Perl 배포판과 함께 보관해야 해요.

마지막으로, Perl 커뮤니티 전체는 코드 소유권에 대한 존중, 예술적 통제에 대한 존중, 적절한 공로, 그리고 의도하지 않은 코드 편향·의사소통 격차를 막기 위한 적극적 노력이 커뮤니티와 Perl 자체의 건강에 필수적임을 인식해요. 커뮤니티 구성원은 보통 서로를 다루는 데 규칙과 법률에 의존해서는 안 되고, 이 문서는 명확성을 위해 규칙을 포함하지만 태도와 일반적 접근에 관한 거예요. 어떤 분쟁에서도 첫 단계는 개방적 의사소통, 반대 관점에 대한 존중, 타협 시도여야 해요. 거의 모든 상황에서 그 이상은 필요 없고, 의사소통과 논의의 모든 통로가 실패하기 전까지는 확실히 더 과감한 조치를 써서는 안 돼요.

문서 (DOCUMENTATION)

Perl의 문서는 사용자에게 중요한 자원이에요. Perl 문서가 합리적으로 일관되고 현재 구현을 정확히 반영하는 것은 믿을 수 없을 만큼 중요해요.

P5P가 공동으로 코드베이스를 유지하듯, 우리는 공동으로 문서를 유지해요. 특정 문서를 쓴다고 해서 그 문서의 미래에 대한 통제가 저자에게 생기진 않아요. 동시에 소스 코드 변경이 주변 블록의 스타일과 맞아야 하듯, 문서 변경도 그래야 해요.

문서의 예시는 그 개념을 설명하는 데 도움이 되어야 해요. 때로는 언어 기능이 어떻게 동작하는지 보여주는 가장 좋은 방법은, 독자가 수정 없이 실행할 수 있는 작은 프로그램이에요. 더 자주, 예시는 "중요한" 부분만 담은 코드 조각으로 구성돼요. "중요한"의 정의는 조각마다 달라요. 때로는 use strict와 use warnings를 선언하고 모든 변수를 초기화하며 모든 오류 조건을 완전히 잡는 게 중요해요. 하지만 더 자주, 그런 것들은 예시가 가르치려는 교훈을 흐리게 해요.

Perl은 전 세계 자원봉사 팀이 개발하므로, 우리 문서는 누군가에게는 이상해 보이는 철자를 자주 담아요. 미국/영국/기타 철자의 선택은 각 문서 작성자의 몫으로 남아 있어요. 문서를 패치할 때는 기존 산문을 바꾸기보다 주변 문서를 흉내 내려고 노력하세요.

일반적으로 문서는 Perl이 "예전에" 무엇을 했는지보다 "지금" 무엇을 하는지 설명해야 해요. 동작이 이전 릴리스에서 어떻게 바뀌었는지 문서에 주석을 포함하는 건 전적으로 합리적이지만, 아주 드문 예외를 제외하면 문서는 "dual-life"가 아니에요. 모든 옛 버전이 어떻게 동작했는지 완전히 설명할 필요는 없어요.

행동 규범 (STANDARDS OF CONDUCT)

perl 개발의 공식 포럼은 앞서 언급한 perl5-porters 메일링 리스트와 GitHub의 버그트래커예요. 리스트와 버그트래커에 게시하는 것은 권리가 아니에요. 논의의 모든 참가자는 행동 규범을 지킬 것으로 기대돼요.

항상 예의를 지켜요.
중재자(moderators)의 말을 따르세요.

예의는 단순해요: 사실에 충실하면서, 상대를 깎아내리는 발언, 비하, 빈정댐, 또는 악의 추정을 피하는 거예요. 사실만으로는 부족해요. 예의도 있어야 해요. 무례함에 무례함으로 대응하는 건 받아들여지지 않아요. 제3자의 게시되지 않은 의견을 리스트에 중계한다면, 그 의견의 내용에 대한 책임을 지는 것이므로 그것들이 예의 있음을 보장해야 해요.

예의가 요구된다면, 친절함은 권장돼요. 자신이 예의 바른지 의심이 든다면 "나는 친절한가?"라고 스스로 물어보고 그렇게 되도록 노력하세요.

리스트 중재자가 당신이 예의 바르지 않다고 말하면, 어떤 방식으로든 응답하기 전에 당신의 말이 어떻게 보였을지 신중히 고려하세요. 그것들은 친절했나요? 항의할 수는 있지만, 반복적으로 재확인된 결정 앞에서 반복적으로 항의하는 건 받아들여지지 않아요. 제3자에 대한 중재자의 결정에 대해 반복적으로 항의하는 것도, 중재자와 그들의 결정에 대해 오프-리스트 접촉을 계속 시작하는 것도 받아들여지지 않아요.

받아들여지지 않는 행동은 공개적이고 명확히 식별된 경고로 이어져요. 같은 개인의 두 번째 허용 불가 행동은 메일링 리스트와 GitHub 이슈 트래커에서 한 달 동안 제외되는 결과를 낳아요. 그 이유는 그 사람이 행동 방식을 바꿀 기회를 제공하기 위해서예요.

기간 제한 반복이 풀린 후 세 번째 허용 불가 행동은 추가 공개 경고로 이어져요. 네 번째 이상의 행동은 무기한 제외로 이어져요. 그 이유는 행동을 바꾸려는 명백한 거부 앞에서, 미래의 허용 불가한 행동으로부터 다른 커뮤니티 구성원을 보호해야 하기 때문이에요. 중재자는 해당 인물이 다시 위반하지 않겠다고 확언하면 무기한 제외를 풀기로 선택할 수 있어요.

제외는 경고처럼 공개적이에요.

중재자 목록은 공개 지식이에요. 현재는: Karen Etheridge, Neil Bowers, Nicholas Clark, Ricardo Signes, Todd Rinaldo예요.