perlpolicy - Online w chmurze

PROGRAM:

IMIĘ

perlpolicy - Różne i rozmaite zasady i zobowiązania związane z rdzeniem Perl

OPIS

Niniejszy dokument jest dokumentem głównym, w którym zapisano wszystkie pisemne zasady dotyczące sposobu korzystania z języka Perl.
Pięciu Porterów wspólnie opracowuje i utrzymuje rdzeń języka Perl.

ZARZĄDZANIE

Perl 5 Portierzy
Subskrybenci perl5-porters (sami porters) występują w kilku odmianach. Niektóre z nich to
cisi ciekawscy tropiciele, którzy rzadko włączają się do akcji i zamiast tego obserwują bieżący rozwój
upewnij się, że są ostrzegani o nowych zmianach lub funkcjach w Perlu. Niektórzy są przedstawicielami
dostawców, którzy dbają o to, aby Perl był nadal kompilowany i działał na ich
platformy. Niektórzy łatają każdy zgłoszony błąd, który potrafią naprawić, niektórzy są aktywni
łatanie ich ulubionego obszaru (wątki, Win32, regexp -engine), podczas gdy inni zdają się to robić
nic tylko narzekać. Innymi słowy, to zwykła mieszanka ludzi technicznych.

Nad tą grupą tragarzy przewodniczy Larry Wall. On ma ostatnie słowo w tym, co robi i
nie zmienia się w żadnym z języków programowania Perl. Obecnie Larry spędza większość
swojego czasu nad Perlem 6, podczas gdy Perlem 5 opiekuje się „pumpking”, tragarz odpowiedzialny
za decydowanie o tym, co znajdzie się w każdym wydaniu i zapewnienie, że wydania będą miały miejsce regularnie
Podstawa.

Larry uważa, że ​​rozwój języka Perl będzie przebiegał zgodnie z linią rządu USA: jest ustawodawca
(tragarze), władza wykonawcza (-pumpking) i Sąd Najwyższy (Larry).
władze ustawodawcze mogą omawiać i przedstawiać poprawki władzy wykonawczej, ile chcą, ale
władza wykonawcza ma prawo je zawetować. Rzadko zdarza się, aby Sąd Najwyższy stanął po stronie
władza wykonawcza nad ustawodawczą lub władza ustawodawcza nad wykonawczą.
Przede wszystkim jednak zakłada się, że władza ustawodawcza i wykonawcza będą się dogadywać i
rozwiązać swoje różnice bez konieczności wszczynania procedury impeachmentu lub prowadzenia spraw sądowych.

Czasami można spotkać się z odniesieniami do Reguły 1 i Reguły 2. Władza Larry’ego jako Sądu Najwyższego to
wyrażone w Regulaminie:

1. Larry z definicji zawsze ma rację co do tego, jak Perl powinien się zachowywać. Oznacza to, że ma
ostateczne prawo weta w stosunku do podstawowej funkcjonalności.

2. Larry ma prawo zmienić zdanie w dowolnej sprawie w późniejszym terminie, niezależnie od
czy wcześniej powołał się na zasadę 1.

Zrozumiano? Larry zawsze ma rację, nawet gdy się myli. Rzadko można zobaczyć Rule'a
wykonywane, ale często się o nich wspomina.

UTRZYMANIE ROLNICZE WSPIERAJ

Perl 5 jest rozwijany przez społeczność, a nie podmiot korporacyjny. Każda zmiana przyczyniła się do
rdzeń Perla jest wynikiem darowizny. Zazwyczaj te darowizny są wkładami
kod lub czas przez poszczególnych członków naszej społeczności. Czasami te darowizny przychodzą
forma korporacyjnego lub organizacyjnego sponsorowania określonej osoby lub projektu.

Jako organizacja wolontariacka, zobowiązania, które podejmujemy, w dużym stopniu zależą od dobrej woli
i ciężka praca osób, które nie mają żadnego obowiązku przyczyniania się do rozwoju Perla.

Mimo to cenimy stabilność i bezpieczeństwo języka Perl i od dawna mamy niespisaną
współpracuje z szerszą społecznością Perla w celu wspierania i utrzymywania wydań języka Perl.

W tym dokumencie określono zobowiązania dotyczące wsparcia i konserwacji, jakie społeczność Perla musi spełnić
należy oczekiwać od twórców języka Perl:

· „Oficjalnie” wspieramy dwie najnowsze serie stabilnych wydań: 5.16.x i wcześniejsze
nie są już wspierane. Od wydania wersji 5.22.0 „oficjalnie” zakończymy wsparcie
dla Perl 5.18.x, poza dostarczaniem aktualizacji zabezpieczeń, jak opisano poniżej.

· W miarę naszych możliwości postaramy się rozwiązać najważniejsze problemy w dwóch najważniejszych
ostatnia stabilna seria wydań 5.x. Poprawki dla bieżącej serii wydań
pierwszeństwo przed poprawkami do poprzednich serii wydań.

· W miarę naszych możliwości będziemy dostarczać „krytyczne” poprawki/wersje zabezpieczeń
jakakolwiek główna wersja Perla, której wydanie 5.x.0 miało miejsce w ciągu ostatnich trzech lat. Możemy
zobowiązujemy się do dostarczania ich wyłącznie w przypadku najnowszej wersji .y w serii 5.xy.

· Nie będziemy udostępniać aktualizacji zabezpieczeń ani poprawek błędów dla wersji rozwojowych języka Perl.

Zachęcamy dostawców do dostarczania najnowszej obsługiwanej wersji języka Perl w momencie
ich kod się zamroził.

· Jako dostawca możesz mieć obowiązek wstecznego przenoszenia poprawek zabezpieczeń poza nasz 3-letni okres
zobowiązanie wsparcia. Możemy zapewnić Ci ograniczone wsparcie i porady, gdy to robisz
i w miarę możliwości postaramy się zastosować te poprawki do odpowiednich gałęzi -maint
git, choć możemy lub nie zdecydować się na wydanie numerowanych wersji lub „oficjalnych” poprawek
dostępne. Skontaktuj się z nami pod adresemperl5-security-raport@perl.org> aby rozpocząć ten proces.

DO TYŁU ZGODNOŚĆ ROLNICZE DEZAPROBATA

W naszej społeczności od dawna panuje przekonanie, że wsteczna kompatybilność jest cnotą, nawet jeśli
funkcjonalność, o której mowa, jest wadą projektu.

Wszyscy chcielibyśmy naprawić błędy, które popełniliśmy w ciągu ostatnich dekad. Życie z
każdy błąd projektowy, jaki kiedykolwiek popełniliśmy, może prowadzić do bolesnej stagnacji. Odkręcanie naszych błędów
jest bardzo, bardzo trudne. Zrobienie tego bez aktywnego szkodzenia naszym użytkownikom jest prawie
niemożliwy.

Ostatnio ignorowanie lub aktywne sprzeciwianie się zgodności ze starszymi wersjami języka Perl stało się powszechne
w modzie. Czasami proponowana jest zmiana, która ma na celu zastąpienie składni, która wcześniej
miało inne znaczenie. Czasami zmiana chce poprawić wcześniej szaloną semantykę.

Ta droga prowadzi do szaleństwa.

Wymaganie od programistów końcowych zmiany zaledwie kilku konstrukcji języka, nawet
konstrukcje, których żaden dobrze wykształcony programista nigdy by celowo nie użył, są równoznaczne z
mówiąc „nie powinieneś aktualizować do nowej wersji Perla, jeśli nie masz 100% pokrycia testami”
i możemy wykonać pełny ręczny audyt Twojej bazy kodu." Gdybyśmy mieli narzędzia zdolne do
niezawodna aktualizacja kodu źródłowego Perla z jednej wersji Perla do innej, to obawa
można by znacznie złagodzić.

Chcemy mieć pewność, że Perl będzie się nadal rozwijał i rozkwitał w nadchodzących latach i
dekad, ale nie kosztem naszej społeczności użytkowników.

Istniejącą składnię i semantykę należy oznaczać do zniszczenia tylko w bardzo ograniczonym zakresie
okoliczności. Jeśli uważa się, że są one używane bardzo rzadko, stoją na drodze rzeczywistego
ulepszenie języka Perl lub interpretatora Perla, a jeśli dotknięty kod można łatwo
zaktualizowane, aby kontynuować pracę, mogą być rozważane do usunięcia. W razie wątpliwości, zachowaj ostrożność
nakazuje, że będziemy faworyzować wsteczną kompatybilność. Kiedy funkcja jest przestarzała,
zostanie opublikowane oświadczenie uzasadniające proces decyzyjny i podany zostanie do niego link
zostaną podane w odpowiednich dokumentach perldelta.

Należy rozważyć użycie pragmatyki leksykalnej w celu włączenia lub wyłączenia starszego zachowania, gdy
odpowiednie i w przypadku braku jakiegokolwiek pragma legacy behavior powinno być włączone. Które
zmiany niekompatybilne z poprzednimi wersjami są kontrolowane w sposób dorozumiany przez decyzję „użyj v5.xy”
które powinno zostać podjęte przez Pumpkinga w porozumieniu ze społecznością.

Historycznie rzecz biorąc, stawialiśmy sobie znacznie wyższe standardy niż zgodność wsteczna –
bugward-compatibility. Każdy przypadek implementacji lub niezamierzony efekt uboczny
uruchomienie pewnego fragmentu kodu jest uważane za cechę języka,
bronione z takim samym zapałem jak każda inna cecha lub funkcjonalność. Bez względu na to, jak
te niezamierzone funkcje mogą być dla nas frustrujące, ponieważ nadal udoskonalamy Perla,
te niezamierzone cechy często zasługują na naszą ochronę. Bardzo ważne jest, aby
istniejące oprogramowanie napisane w Perlu nadal działa poprawnie. Jeśli programiści końcowi mają
przyjęliśmy błąd jako funkcję, musimy go tak traktować.

Nowa składnia i semantyka, które nie łamią istniejących konstrukcji językowych i składni, mają
znacznie niższy poziom. Muszą jedynie udowodnić, że są użyteczni, eleganccy, dobrze
zaprojektowane i dobrze przetestowane. W większości przypadków te dodatki będą oznaczone jako eksperymentalny
przez jakiś czas. Więcej na ten temat poniżej.

Terminologia
Aby mieć pewność, że mówimy o tym samym, gdy omawiamy usuwanie funkcji lub
funkcjonalności z rdzenia Perla, mamy konkretne definicje kilku słów i
zwroty.

eksperymentalny
Jeżeli coś w rdzeniu Perla jest oznaczone jako eksperymentalnymożemy zmienić jego zachowanie,
odrzucić lub usunąć bez powiadomienia. Chociaż zawsze dołożymy wszelkich starań, aby złagodzić
w celu uzyskania informacji o ścieżce przejścia dla użytkowników funkcji eksperymentalnych należy skontaktować się z
perl5-porters mailinglist jeśli uważasz, że eksperymentalna funkcja jest przydatna i chcesz pomóc
kształtować swoją przyszłość.

Funkcje eksperymentalne muszą być eksperymentalne w dwóch stabilnych wersjach przed oznaczeniem
nieeksperymentalne. Funkcje eksperymentalne będą miały tylko status eksperymentalny
odwołane, gdy nie mają już żadnych otwartych błędów zmieniających projekt i gdy
ich zachowanie nie ulega zmianie przez cały cykl rozwojowy.
Innymi słowy, funkcja obecna w wersji 5.20.0 może zostać oznaczona jako nieeksperymentalna w
v5.22.0 wtedy i tylko wtedy, gdy jego zachowanie nie uległo zmianie przez cały okres obowiązywania wersji v5.21.

przestarzałe
Jeżeli coś w rdzeniu Perla jest oznaczone jako przestarzałemożemy usunąć go z rdzenia
w przyszłości, choć może nie. Generalnie, zmiany wstecznie niekompatybilne będą
mają ostrzeżenia o wycofaniu przez dwa cykle wydań przed usunięciem, ale mogą być
usuwane już po jednym cyklu, jeśli ryzyko wydaje się stosunkowo niskie lub korzyści stosunkowo wysokie.

Od wersji Perl 5.12 przestarzałe funkcje i moduły ostrzegają użytkownika podczas ich używania. Kiedy
moduł jest przestarzały, będzie również dostępny na CPAN. Instalacja z
CPAN wyciszy ostrzeżenia o wycofaniu danego modułu.

Jeśli używasz przestarzałej funkcji lub modułu i uważasz, że jej usunięcie z języka Perl
core byłoby błędem, skontaktuj się z listą mailingową perl5-porters i poproś o pomoc
przypadku. Nie deprecjonujemy rzeczy bez dobrego powodu, ale czasami jest
kontrargument, którego nie rozważaliśmy. Historycznie nie rozróżnialiśmy między
funkcje „przestarzałe” i „niezalecane”.

zniechęcony
Od czasu do czasu możemy oznaczać konstrukcje i cechy języka, które uważamy za
były błędy jako zniechęcony. Zniechęcane funkcje nie są obecnie kandydatami
do usunięcia, ale możemy je później odrzucić, jeśli okaże się, że stoją na przeszkodzie
znacząca poprawa jądra Perla.

usunięte
Po oznaczeniu funkcji, konstrukcji lub modułu jako przestarzałego możemy go usunąć
z rdzenia Perla. Nic dziwnego, że mówimy, że mamy usunięte te rzeczy. Kiedy moduł
zostanie usunięty, nie będzie już dostarczany z Perlem, ale nadal będzie dostępny w
CPAN.

UTRZYMANIE ODDZIAŁY

Nowe wersje gałęzi konserwacyjnych powinny zawierać wyłącznie zmiany, które mieszczą się w jednym z następujących obszarów:
„dopuszczalnych” kategorii określonych poniżej, ale nie mogą zawierać żadnych zmian mieszczących się w jednej z nich
kategorii „niedopuszczalne”. (Na przykład poprawka na błąd powodujący awarię nie może być
(uwzględnione, jeśli narusza zgodność binarną.)

Nie jest konieczne uwzględnianie każdej zmiany spełniającej te kryteria, a ogólnie rzecz biorąc
należy skupić się na rozwiązywaniu problemów bezpieczeństwa, błędach powodujących awarie, regresjach i poważnych
problemy z instalacją. Pokusa uwzględnienia mnóstwa drobnych zmian, które nie
wpływać na instalację lub wykonywanie języka Perl (np. poprawki pisowni w dokumentacji)
należy się temu oprzeć, aby zmniejszyć ogólne ryzyko przeoczenia czegoś.
intencją jest tworzenie wersji konserwacyjnych, które są zarówno wartościowe, jak i dostępne dla użytkowników
mieć pełne zaufanie do stabilności. (Drugorzędną kwestią jest uniknięcie wypalenia zawodowego
utrzymywanie i pompowanie lub przytłaczanie innych członków zespołu do głosowania nad zmianami, które mają zostać uwzględnione (zobacz
„Wprowadzanie zmian do gałęzi maint” poniżej).)

Następujące rodzaje zmian można uznać za dopuszczalne, o ile nie powodują one również:
nie mieści się w żadnej z kategorii „niedopuszczalnych” określonych poniżej:

· Poprawki naprawiające CVE lub problemy z bezpieczeństwem. Te zmiany powinny zostać uruchomione przez
perl5-security-raport@perl.org listy mailingowej, a nie bezpośrednio aplikować.

· Poprawki naprawiające błędy powodujące awarie, błędy asercji i uszkodzenia pamięci, ale nie
nie zmieniać funkcjonalności języka Perl ani nie wpływać negatywnie na wydajność.

· Poprawki naprawiające regresje w zachowaniu języka Perl w porównaniu do poprzednich wersji, nie
nie ma znaczenia, jak stara jest regresja, ponieważ niektórzy użytkownicy mogą uaktualniać bardzo stare wersje
perl do najnowszej wersji.

· Poprawki naprawiające błędy w funkcjach, które były nowe w odpowiedniej stabilnej wersji 5.x.0
zwolnić.

· Poprawki naprawiające wszystko, co uniemożliwia lub poważnie wpływa na kompilację lub
instalacja perla.

· Poprawki przenośności, takie jak zmiany w programie Configure oraz plikach w folderze hints/.

· Minimalne poprawki naprawiające błędy testów specyficzne dla danej platformy.

· Aktualizacje dokumentacji, które korygują błędy rzeczowe, wyjaśniają istotne błędy lub
niedociągnięcia w obecnej implementacji lub naprawa uszkodzonego znacznika.

· Aktualizacje modułów dual-life powinny składać się z minimalnych poprawek naprawiających błędy powodujące awarie lub
kwestie bezpieczeństwa (jak wyżej). Wszelkie zmiany wprowadzone do modułów dual-life, dla których CPAN jest
kwestie kanoniczne należy koordynować z autorem źródłowym.

Następujące rodzaje zmian NIE są dopuszczalne:

· Poprawki, które naruszają zgodność binarną. (Proszę porozmawiać z pumpking.)

· Poprawki dodające lub usuwające funkcje.

· Poprawki dodające nowe ostrzeżenia lub błędy albo wycofujące funkcje.

· Porty języka Perl na nową platformę, architekturę lub wersję systemu operacyjnego, które wymagają zmian w
Wdrożenie.

· Nowych wersji modułów dual-life NIE należy importować do maint. Te należą do
następna stabilna seria.

Jeśli masz jakiekolwiek wątpliwości, czy dana poprawka zasługuje na uwzględnienie w aktualizacji
wydanie, to prawie na pewno nie powinno zostać uwzględnione.

Dojazd zmiany najnowszych a utrzymuje oddział
Historycznie, tylko wybrane zmiany z bleadperl na maintperl były robione na pumpking.
ma problemy ze skalowaniem. Jednocześnie gałęzie konserwacyjne stabilnych wersji Perla
należy traktować z wielką ostrożnością. W tym celu, od Perl 5.12, mamy nowy proces
dla oddziałów konserwacyjnych.

Każdy committer może wybrać dowolne zatwierdzenie z gałęzi blead do gałęzi maint, jeśli wyśle ​​wiadomość e-mail do
perl5-porters ogłaszają swój zamiar wybrania konkretnego zatwierdzenia wraz z
uzasadnienie takiego działania i co najmniej dwóch innych zatwierdzających odpowiada na listę, podając swoje
zgoda. (Niniejsza polityka dotyczy obecnych i byłych użytkowników Pumpkings, a także innych
(komitetów.)

Zamiast tego można zastosować inne mechanizmy głosowania, pod warunkiem że wymagana jest taka sama liczba głosów.
zebrane w sposób przejrzysty. Konkretnie, propozycje zmian, które mają być wybierane
musi być widoczny dla wszystkich na perl5-porters, aby poglądy wszystkich zainteresowanych mogły być
być usłyszanym.

Nie jest konieczne przeprowadzanie głosowania nad wybieraniem wpisów perldelta powiązanych
ze zmianami, które zostały już wybrane, ani dla utrzymania pompowania, aby uzyskać
głosowania nad zmianami wymaganymi przez Porting/release_managers_guide.pod gdzie takie zmiany mogą
należy stosować metodą wybiórczego pobierania krwi.

WSPÓŁPRACOWANO MODUŁY

A Obserwuj Nas Umowa Parę słów o Artystyczny Control:
Poniżej znajduje się oświadczenie dotyczące kontroli artystycznej, definiowanej jako zdolność autorów
pakiety, aby kierować przyszłością swojego kodu i zachować kontrolę nad swoją pracą. To jest
uznanie, że autorzy powinni mieć kontrolę nad swoją pracą i że jest to
Obowiązkiem reszty społeczności Perl jest zapewnienie utrzymania tej kontroli.
Jest to próba udokumentowania standardów, których my, jako programiści języka Perl, zamierzamy się trzymać
siebie. Jest to próba spisania ogólnych wytycznych dotyczących szacunku, jaki jesteśmy winni sobie nawzajem
inni jako programiści języka Perl.

Niniejsze oświadczenie nie jest umową prawną. Niniejsze oświadczenie nie jest dokumentem prawnym w żadnym
sposób, kształt lub formę. Perl jest rozpowszechniany na licencji GNU Public License i na warunkach
Licencja artystyczna; to są dokładne terminy prawne. To oświadczenie nie dotyczy prawa
lub licencji. Chodzi o społeczność, wzajemny szacunek, zaufanie i współpracę w dobrej wierze.

Uznajemy, że rdzeń Perla, zdefiniowany jako oprogramowanie dystrybuowane z sercem
Perl sam w sobie jest wspólnym projektem nas wszystkich. Od czasu do czasu skrypt,
moduł lub zestaw modułów (zwany dalej po prostu „modułem”) udowodni, że
powszechnie użyteczne i/lub tak istotne dla prawidłowego funkcjonowania samego języka Perl, że powinno
być dystrybuowane z rdzeniem Perl. Nigdy nie powinno się tego robić bez zgody autora
wyraźna zgoda i jasne uznanie przez wszystkie strony, że oznacza to, że moduł jest
dystrybuowane na tych samych zasadach co sam Perl. Autor modułu powinien zdawać sobie sprawę, że
włączenie modułu do jądra Perla będzie wiązało się z utratą kontroli nad nim
ponieważ czasami może zaistnieć konieczność wprowadzenia zmian w krótkim terminie lub w celu zachowania spójności
reszta Perla.

Gdy jednak moduł zostanie uwzględniony w jądrze języka Perl, wszyscy zaangażowani w jego tworzenie będą musieli:
osoby zajmujące się utrzymaniem języka Perl powinny pamiętać, że moduł jest nadal własnością oryginału
autor, chyba że pierwotny autor wyraźnie zrzeknie się swojej własności.
konkretny:

· Wersję modułu w jądrze Perla należy nadal uważać za dzieło
oryginalny autor. Wszystkie poprawki, raporty o błędach itp. powinny być im przekazywane.
Należy zawsze, gdy jest to możliwe, respektować kierunki ich rozwoju.

· Łatki mogą być nakładane przez posiadacza dyni bez wyraźnej współpracy
autora modułu, jeśli i tylko jeśli są one bardzo nieistotne i w jakiś sposób krytyczne czasowo (np.
jako pilne poprawki bezpieczeństwa) lub jeśli nie można nawiązać kontaktu z autorem modułu. Te poprawki
należy je nadal zwrócić autorowi, gdy jest to możliwe, a jeśli autor zdecyduje się na
alternatywną poprawkę w ich wersji, ta poprawka powinna być zdecydowanie preferowana, chyba że istnieje
poważny problem z tym. Wszelkie zmiany nie zatwierdzone przez autora powinny być oznaczone jako
takie, a osoba, która przyczyniła się do zmiany, została uznana.

· Wersja modułu dystrybuowana z Perlem powinna być, o ile to możliwe,
najnowsza wersja modułu rozpowszechniana przez autora (najnowsza wersja niebędąca wersją beta)
w przypadku publicznych wydań języka Perl), chociaż posiadacz dyni może wstrzymać się z
uaktualnianie wersji modułu dystrybuowanego z Perlem do najnowszej wersji do czasu
najnowsza wersja przeszła wystarczającą liczbę testów.

Innymi słowy, autor modułu powinien być uważany za osobę mającą ostatnie słowo w tej sprawie.
modyfikacje swojego modułu, kiedy tylko jest to możliwe (mając na uwadze, że oczekuje się, że
wszyscy zaangażowani będą ze sobą współpracować i dochodzić do rozsądnych kompromisów, gdy zajdzie taka potrzeba
nieporozumienia).

W ostateczności jednak:

Jeżeli wizja autora dotycząca przyszłości jego modułu jest wystarczająco odmienna od
wizja posiadacza dyni i perl5-porterów jako całości, co może powodować poważne problemy
w przypadku języka Perl posiadacz dyni może zdecydować się na formalne rozwidlenie wersji modułu w
Rdzeń Perla z tego, który utrzymuje autor. Nie powinno się tego robić lekko i
powinien zawsze jeśli to możliwe, należy to zrobić tylko po bezpośrednim wprowadzeniu danych przez Larry'ego. Jeśli to jest
po wykonaniu tej czynności należy to wyraźnie zaznaczyć w module dystrybuowanym wraz z rdzeniem Perla,
jest to wersja rozwidlona i chociaż opiera się na pracy oryginalnego autora, nie jest
dłużej przez nich utrzymywane. Należy to odnotować zarówno w dokumentacji, jak i w
komentarze w źródle modułu.

Ponownie, powinno to być ostatecznością. W idealnym przypadku nigdy nie powinno się to zdarzyć, a każdy
możliwe wysiłki na rzecz współpracy i kompromisu powinny zostać podjęte przed zrobieniem tego. Jeśli to
jeśli okaże się konieczne rozwidlenie modułu dla ogólnego stanu zdrowia Perla, należy oddać mu należytą odpowiedzialność
zostać przekazane pierwotnemu autorowi na zawsze, a decyzja ta powinna być stale odnawiana
poddano ocenie, czy w przyszłości możliwe będzie ponowne połączenie obu gałęzi.

W przypadku wszelkich kontaktów z modułami wniesionymi, każdy, kto zajmuje się utrzymaniem języka Perl, powinien pamiętać
że kod należy do oryginalnego autora i że nie może on znajdować się w żadnym momencie na perl5-porters
z upływem określonego czasu i że poprawka nie jest oficjalna, dopóki nie zostanie zintegrowana z
egzemplarz modułu dla autora. Aby pomóc w tym, a także w punktach #1, #2 i #3 powyżej,
dane kontaktowe autorów wszystkich dodanych modułów powinny być przechowywane w
Dystrybucja Perla.

Na koniec, cała społeczność Perla uznaje, że szacunek dla własności kodu,
szacunek dla kontroli artystycznej, właściwe uznanie autorstwa i aktywne działania mające na celu zapobieganie niezamierzonemu
błędy w kodzie i luki w komunikacji mają kluczowe znaczenie dla zdrowia społeczności i samego języka Perl.
Członkowie społeczności nie powinni zazwyczaj musieć odwoływać się do zasad i praw, aby radzić sobie z problemami.
wzajemnie, a niniejszy dokument, mimo że zawiera zasady, które mają na celu zapewnienie jasności, dotyczy
postawa i ogólne podejście. Pierwszy krok w każdym sporze powinien być otwarty
komunikacja, szacunek dla przeciwstawnych poglądów i próba kompromisu. W prawie
w każdej sytuacji nie będzie konieczne nic więcej, a już na pewno nie będzie bardziej drastycznych środków
należy stosować dopóki nie zawiodą wszystkie sposoby komunikacji i dyskusji.

DOKUMENTACJA

Dokumentacja Perla jest ważnym źródłem dla naszych użytkowników. Jest niezwykle ważna dla
Dokumentacja języka Perl powinna być w miarę spójna i dokładnie odzwierciedlać aktualny stan wiedzy.
realizacja.

Podobnie jak P5P wspólnie utrzymuje bazę kodu, wspólnie utrzymujemy
dokumentacja. Napisanie konkretnego fragmentu dokumentacji nie daje autorowi kontroli
przyszłości tej dokumentacji. W tym samym czasie, tak jak zmiany w kodzie źródłowym powinny
powinny pasować do stylu otaczających je bloków, dlatego zmiany w dokumentacji również powinny być wprowadzane.

Przykłady w dokumentacji powinny ilustrować omawianą koncepcję.
Czasami najlepszym sposobem pokazania, jak działa funkcja języka, jest użycie małego programu.
czytelnik może uruchomić bez modyfikacji. Częściej przykłady będą składać się z fragmentu
kod zawierający tylko „ważne” bity. Definicja „ważnego” różni się od
fragment do fragmentu. Czasami ważne jest, aby zadeklarować „use strict” i „use warnings”,
zainicjuj wszystkie zmienne i w pełni wyłap każdy warunek błędu. Najczęściej,
Jednakże te rzeczy przesłaniają lekcję, której przykład ten miał nauczać.

Ponieważ Perl jest rozwijany przez globalny zespół wolontariuszy, nasza dokumentacja często zawiera
pisowni, która wygląda śmiesznie ktośWybór pisowni amerykańskiej/brytyjskiej/innej to
pozostawione jako ćwiczenie dla autora każdego fragmentu dokumentacji. Podczas łatania
dokumentacji, staraj się naśladować dokumentację, która cię otacza, zamiast ją zmieniać
istniejąca proza.

Ogólnie rzecz biorąc, dokumentacja powinna opisywać, co Perl robi „teraz”, a nie to, co robił kiedyś
zrób. Zupełnie rozsądne jest dołączanie notatek do dokumentacji na temat tego, jak zachowanie ma
zmienione w stosunku do poprzednich wersji, ale z niewieloma wyjątkami dokumentacja nie jest „podwójna”
„life” – nie trzeba w nim dokładnie opisywać, jak działały wszystkie stare wersje.

NORMY OF POSTĘPEK

Oficjalnym forum rozwoju języka Perl jest lista mailingowa perl5-porters,
wspomniano powyżej, a jego bugtracker na rt.perl.org. Wszyscy uczestnicy dyskusji tam
Oczekuje się, że będą przestrzegać standardów postępowania.

· Zawsze zachowuj się kulturalnie.

· Słuchaj moderatorów.

Kultura jest prosta: trzymaj się faktów, unikając poniżających uwag i sarkazmu.
nie wystarczy być faktem. Musisz być również kulturalny. Odpowiadanie w naturze na nieuprzejmość jest
nie do przyjęcia.

Choć wymagana jest uprzejmość, zachęcamy do życzliwości; jeśli masz jakiekolwiek wątpliwości, czy
jeśli jesteś uprzejmy, po prostu zapytaj siebie: „Czy jestem miły?” i dąż do tego.

Jeśli moderatorzy listy powiedzą Ci, że nie zachowujesz się kulturalnie, dokładnie przemyśl swoje zachowanie.
słowa pojawiły się przed udzieleniem odpowiedzi w jakikolwiek sposób. Czy były miłe? Możesz protestować, ale
powtarzające się protesty w obliczu wielokrotnie potwierdzanej decyzji są niedopuszczalne.

Niedopuszczalne zachowanie będzie skutkować publicznym i wyraźnie określonym ostrzeżeniem. Powtarzane
nieodpowiednie zachowanie będzie skutkować usunięciem z listy mailingowej i cofnięciem
prawa do aktualizacji rt.perl.org. Pierwsze usunięcie jest na jeden miesiąc. Kolejne usunięcia
podwoi długość. Po sześciu miesiącach bez ostrzeżenia długość bana użytkownika zostanie zresetowana.
Usunięcia, podobnie jak ostrzeżenia, są publiczne.

Lista moderatorów będzie publicznie znana. Obecnie są to: Aaron Crane, Andy
Dougherty, Ricardo Signes, Steffen Mueller.

KREDYTY

„Umowa społeczna dotycząca modułów wniesionych” pierwotnie autorstwa Russa Allbery’egorra@stanford.edu>
i porty perl5.

Użyj perlpolicy online korzystając z usług onworks.net