perlpolicy - Online nel cloud

PROGRAMMA:

NOME

perlpolicy - Politiche e impegni vari e vari relativi al core Perl

DESCRIZIONE

Questo documento è il documento principale che registra tutte le politiche scritte su come Perl
5 porter sviluppano e mantengono collettivamente il core Perl.

AMMINISTRAZIONE

Perl 5 Facchini
Gli abbonati a perl5-porter (i porter stessi) sono disponibili in diverse versioni. Alcuni sono
tranquilli curiosi in agguato, che raramente intervengono e invece guardano lo sviluppo in corso per
assicurati che siano avvisati di nuove modifiche o funzionalità in Perl. Alcuni sono rappresentanti di
fornitori, che sono lì per assicurarsi che Perl continui a compilare e lavorare sui loro
piattaforme. Alcuni correggono qualsiasi bug segnalato che sanno come correggere, altri lo sono attivamente
patchare la loro area preferita (thread, Win32, il regexp -engine), mentre altri sembrano farlo
altro che lamentarsi. In altre parole, è il solito mix di tecnici.

Su questo gruppo di facchini presiede Larry Wall. Ha l'ultima parola in ciò che fa e
non cambia in nessuno dei linguaggi di programmazione Perl. In questi giorni, Larry spende di più
del suo tempo su Perl 6, mentre Perl 5 è guidato da un "pumpking", un portiere responsabile
per decidere cosa inserire in ogni versione e garantire che le versioni avvengano regolarmente
base.

Larry vede lo sviluppo di Perl sulla falsariga del governo degli Stati Uniti: c'è la legislatura
(i facchini), il ramo esecutivo (il -pumpking), e la Corte Suprema (Larry). Il
il legislatore può discutere e presentare patch al ramo esecutivo quanto vuole, ma il
il potere esecutivo è libero di porre loro il veto. Raramente, la Corte Suprema si schiererà con il
potere esecutivo sul potere legislativo, o il potere legislativo sul potere esecutivo.
Per lo più, tuttavia, il potere legislativo e il potere esecutivo dovrebbero andare d'accordo e
risolvere le loro differenze senza impeachment o casi giudiziari.

A volte potresti vedere riferimenti alla Regola 1 e alla Regola 2. Il potere di Larry come Corte Suprema è
espresso nel Regolamento:

1. Larry ha sempre ragione per definizione su come dovrebbe comportarsi Perl. Questo significa che ha
potere di veto finale sulla funzionalità principale.

2. A Larry è consentito cambiare idea su qualsiasi questione in un secondo momento, indipendentemente da
se ha precedentemente invocato la Regola 1.

Capito? Larry ha sempre ragione, anche quando aveva torto. È raro vedere una delle due regole
esercitate, ma a cui spesso si allude.

MANUTENZIONE E SUPPORTO

Perl 5 è sviluppato da una comunità, non da un'entità aziendale. Ogni cambiamento ha contribuito a
il core Perl è il risultato di una donazione. In genere, queste donazioni sono contributi di
codice o tempo dai singoli membri della nostra comunità. A volte, queste donazioni arrivano
la forma di sponsorizzazione aziendale o organizzativa di un particolare individuo o progetto.

Come organizzazione di volontariato, gli impegni che prendiamo dipendono fortemente dalla buona volontà
e il duro lavoro di individui che non hanno alcun obbligo di contribuire a Perl.

Detto questo, apprezziamo la stabilità e la sicurezza di Perl e abbiamo avuto a lungo un non scritto
patto con la più ampia comunità Perl per supportare e mantenere le versioni di Perl.

Questo documento codifica gli impegni di supporto e manutenzione che la comunità Perl
dovrebbe aspettarsi dagli sviluppatori di Perl:

· Supportiamo "ufficialmente" le due serie di versioni stabili più recenti. 5.16.x e versioni precedenti
sono ora senza supporto. A partire dal rilascio di 5.22.0, termineremo "ufficialmente" il supporto
per Perl 5.18.x, oltre a fornire aggiornamenti di sicurezza come descritto di seguito.

· Al meglio delle nostre capacità, cercheremo di risolvere i problemi critici nei due più
recente serie di versioni 5.x stabili. Correzioni per la serie di versioni correnti take
precedenza sulle correzioni per la serie di versioni precedenti.

· Al meglio delle nostre capacità, forniremo patch/rilasci di sicurezza "critici" per
qualsiasi versione principale di Perl il cui rilascio 5.x.0 è stato effettuato negli ultimi tre anni. Noi possiamo
impegnarsi a fornirli solo per la versione .y più recente di qualsiasi serie 5.xy.

· Non forniremo aggiornamenti di sicurezza o correzioni di bug per le versioni di sviluppo di Perl.

· Incoraggiamo i fornitori a spedire la versione supportata più recente di Perl al momento del
il loro codice si blocca.

· In qualità di fornitore, potresti avere l'obbligo di eseguire il backport delle correzioni di sicurezza oltre i nostri 3 anni
impegno di sostegno. Possiamo fornirti supporto e consigli limitati mentre lo fai
e, ove possibile, proverà ad applicare quelle patch ai relativi rami -maint in
git, anche se potremmo scegliere o meno di fare versioni numerate o patch "ufficiali"
a disposizione. Contattaci al[email protected]> per iniziare quel processo.

INDIETRO COMPATIBILITA ' E DEPRECAZIONE

La nostra comunità crede da tempo che la compatibilità con le versioni precedenti sia una virtù, anche quando
la funzionalità in questione è un difetto di progettazione.

Tutti vorremmo disfare alcuni errori che abbiamo commesso negli ultimi decenni. Vivere con
ogni errore di progettazione che abbiamo mai fatto può portare a una dolorosa stagnazione. Risolvere i nostri errori
è molto, molto difficile. Farlo senza danneggiare attivamente i nostri utenti è quasi
impossibile.

Ultimamente è arrivata la possibilità di ignorare o opporsi attivamente alla compatibilità con le versioni precedenti di Perl
in voga. A volte viene proposta una modifica che vuole usurpare la sintassi che in precedenza
aveva un altro significato. A volte, un cambiamento vuole migliorare la semantica precedentemente pazza.

Lungo questa strada giace la follia.

Richiedere ai programmatori dell'utente finale di modificare solo alcuni costrutti del linguaggio, anche il linguaggio
costrutti che nessuno sviluppatore ben istruito utilizzerebbe mai intenzionalmente equivale a
dicendo "non dovresti eseguire l'aggiornamento a una nuova versione di Perl a meno che tu non abbia una copertura di test del 100%
e possiamo eseguire un controllo manuale completo della tua base di codice." Se dovessimo avere strumenti in grado di
aggiornare in modo affidabile il codice sorgente Perl da una versione di Perl a un'altra, questo problema
potrebbe essere notevolmente attenuato.

Vogliamo assicurarci che Perl continui a crescere e prosperare nei prossimi anni e
decenni, ma non a spese della nostra comunità di utenti.

La sintassi e la semantica esistenti dovrebbero essere contrassegnate per la distruzione solo in casi molto limitati
circostanze. Se si ritiene che vengano utilizzati molto raramente, ostacolare l'effettivo
miglioramento del linguaggio Perl o dell'interprete Perl, e se il codice interessato può essere facilmente
aggiornati per continuare a funzionare, possono essere considerati per la rimozione. In caso di dubbio, cautela
impone che favoriremo la retrocompatibilità. Quando una funzionalità è deprecata, a
verrà pubblicata una motivazione che descrive il processo decisionale e un collegamento ad essa
saranno fornite nei relativi documenti perldelta.

L'utilizzo di un pragma lessicale per abilitare o disabilitare il comportamento legacy dovrebbe essere considerato quando
appropriato e, in assenza di qualsiasi pragma, il comportamento legacy dovrebbe essere abilitato. Quale
le modifiche incompatibili con le versioni precedenti sono controllate implicitamente da una decisione "usa v5.xy"
che dovrebbe essere fatto dalla zucca in consultazione con la comunità.

Storicamente, ci siamo tenuti a uno standard molto più elevato rispetto alla compatibilità con le versioni precedenti:
compatibilità bugward. Qualsiasi incidente di attuazione o effetto collaterale non intenzionale di
l'esecuzione di un po' di codice è stata considerata una caratteristica del linguaggio futuro
difeso con lo stesso zelo di qualsiasi altra caratteristica o funzionalità. Non importa come
frustrare queste funzionalità non intenzionali potrebbe essere per noi mentre continuiamo a migliorare Perl,
queste caratteristiche non intenzionali spesso meritano la nostra protezione. È molto importante che
il software esistente scritto in Perl continua a funzionare correttamente. Se gli sviluppatori degli utenti finali hanno
adottato un bug come caratteristica, dobbiamo trattarlo come tale.

La nuova sintassi e semantica che non interrompono i costrutti e la sintassi del linguaggio esistenti hanno a
barra molto più bassa. Hanno solo bisogno di dimostrare di essere utili, eleganti, beh
progettato e ben testato. Nella maggior parte dei casi, queste aggiunte saranno contrassegnate come sperimentale
per un po 'di tempo. Vedi sotto per saperne di più.

Terminologia
Per essere sicuri che stiamo parlando della stessa cosa quando discutiamo della rimozione di funzionalità o
funzionalità dal core Perl, abbiamo definizioni specifiche per poche parole e
frasi.

sperimentale
Se qualcosa nel core Perl è contrassegnato come sperimentale, possiamo cambiarne il comportamento,
deprecato o rimuoverlo senza preavviso. Mentre faremo sempre del nostro meglio per appianare il
percorso di transizione per gli utenti delle funzionalità sperimentali, è necessario contattare il
mailing list perl5-porters se trovi utile una funzione sperimentale e vuoi aiutare
plasmare il suo futuro.

Le funzionalità sperimentali devono essere sperimentali in due versioni stabili prima di essere contrassegnate
non sperimentale. Le funzioni sperimentali avranno solo il loro stato sperimentale
revocato quando non hanno più bug di modifica del design aperti contro di loro e quando
sono rimasti invariati nel comportamento per l'intera durata di un ciclo di sviluppo.
In altre parole, una funzionalità presente nella v5.20.0 può essere contrassegnata come non più sperimentale in
v5.22.0 se e solo se il suo comportamento è rimasto invariato per tutta la v5.21.

deprecato
Se qualcosa nel core Perl è contrassegnato come deprecato, possiamo rimuoverlo dal nucleo
in futuro, anche se potremmo non farlo. In genere, le modifiche incompatibili con le versioni precedenti lo faranno
avere avvisi di deprecazione per due cicli di rilascio prima di essere rimossi, ma potrebbe essere
rimosso dopo un solo ciclo se il rischio sembra piuttosto basso o i benefici piuttosto elevati.

A partire da Perl 5.12, funzioni e moduli deprecati avvisano l'utente quando vengono utilizzati. quando
un modulo è deprecato, sarà reso disponibile anche su CPAN. Installandolo da
CPAN disattiverà gli avvisi di deprecazione per quel modulo.

Se usi una funzionalità o un modulo deprecato e ritieni che la sua rimozione dal Perl
core sarebbe un errore, per favore contatta la mailing list di perl5-porters e permetti la tua
Astuccio. Non deprechiamo le cose senza una buona ragione, ma a volte c'è un
controargomentazione che non abbiamo considerato. Storicamente, non abbiamo fatto distinzioni tra
caratteristiche "deprecate" e "scoraggiate".

sfiduciato
Di tanto in tanto, possiamo contrassegnare costrutti e caratteristiche del linguaggio che consideriamo
sono stati errori come sfiduciato. Le funzionalità scoraggiate non sono attualmente candidate
per la rimozione, ma in seguito potremmo deprecarli se si trovano a ostacolare un
miglioramento significativo del core Perl.

rimosso
Una volta che una caratteristica, un costrutto o un modulo è stato contrassegnato come deprecato, possiamo rimuoverlo
dal nucleo Perl. Non sorprende che diciamo che abbiamo rimosso queste cose. Quando un modulo
viene rimosso, non verrà più spedito con Perl, ma continuerà ad essere disponibile su
CPAN.

MANUTENZIONE FILIALI

Le nuove versioni dei rami di manutenzione devono contenere solo le modifiche che rientrano in una delle
categorie "accettabili" indicate di seguito, ma non devono contenere modifiche che rientrino in una sola
delle categorie "inaccettabili". (Ad esempio, una correzione per un bug che si arresta in modo anomalo non deve essere
incluso se interrompe la compatibilità binaria.)

Non è necessario includere tutte le modifiche che soddisfano questi criteri e, in generale, il
l'attenzione dovrebbe essere sull'affrontare problemi di sicurezza, bug di arresto anomalo, regressioni e gravi
problemi di installazione. La tentazione di includere una pletora di modifiche minori che non lo fanno
influenzare l'installazione o l'esecuzione di perl (es. correzioni ortografiche nella documentazione)
dovrebbe essere contrastato per ridurre il rischio complessivo di trascurare qualcosa. Il
l'intenzione è quella di creare rilasci di manutenzione che valgano la pena e che gli utenti possano
avere piena fiducia nella stabilità di. (Una preoccupazione secondaria è evitare di esaurirsi
il maint-pumping o sopraffare altri committer votando sulle modifiche da includere (vedi
"Inserimento delle modifiche in un ramo principale" di seguito).)

I seguenti tipi di modifica possono essere considerati accettabili, purché non lo siano anche
rientrano in una delle categorie "inaccettabili" di seguito indicate:

· Patch che risolvono CVE o problemi di sicurezza. Queste modifiche dovrebbero essere eseguite attraverso il
[email protected] mailing list piuttosto che applicata direttamente.

· Patch che risolvono bug di arresto anomalo, errori di asserzione e danneggiamento della memoria ma che lo fanno
non modificare in altro modo la funzionalità di perl o influire negativamente sulle prestazioni.

· Patch che risolvono le regressioni nel comportamento di perl rispetto alle versioni precedenti, no
importa quanti anni ha la regressione, dal momento che alcune persone potrebbero aggiornare da versioni molto vecchie di
perl all'ultima versione.

· Patch che risolvono bug nelle funzionalità che erano nuove nella corrispondente stable 5.x.0
rilasciare.

· Patch che riparano tutto ciò che impedisce o influisce seriamente sulla build o
installazione di perl.

· Correzioni alla portabilità, come le modifiche a Configura e ai file nella cartella dei suggerimenti/.

· Patch minime che risolvono errori di test specifici della piattaforma.

· Aggiornamenti della documentazione che correggono errori di fatto, spiegano bug significativi o
carenze nell'implementazione corrente o correggere il markup non funzionante.

· Gli aggiornamenti ai moduli dual-life dovrebbero consistere in patch minime per correggere bug che si bloccano o
problemi di sicurezza (come sopra). Eventuali modifiche apportate ai moduli a doppia vita per i quali CPAN è
canonico dovrebbe essere coordinato con l'autore a monte.

I seguenti tipi di modifica NON sono accettabili:

· Patch che interrompono la compatibilità binaria. (Per favore, parla con uno zucchetto.)

· Patch che aggiungono o rimuovono funzionalità.

· Patch che aggiungono nuovi avvisi o errori o rendono obsolete le funzionalità.

· Port di Perl su una nuova piattaforma, architettura o versione del sistema operativo che comportano modifiche a
l'implemento.

· Le nuove versioni dei moduli dual-life NON devono essere importate in maint. quelli appartengono a
la prossima serie stabile.

Se c'è qualche domanda sul fatto che una data patch possa meritare l'inclusione in un maint
rilascio, quindi quasi certamente non dovrebbe essere incluso.

ottenere i cambiamenti ai miglioramenti a maint ramo
Storicamente, solo la zucca cherry-raccolta cambia da bleadperl a maintperl. Questo
ha problemi di scala. Allo stesso tempo, i rami di manutenzione delle versioni stabili di Perl
devono essere trattati con grande cura. A tal fine, a partire da Perl 5.12, abbiamo un nuovo processo
per la manutenzione delle filiali.

Qualsiasi committer può selezionare qualsiasi commit da blead a un ramo maint se invia posta a
perl5-porters che annunciano la loro intenzione di selezionare un commit specifico insieme a a
razionale per farlo e almeno altri due committer rispondono alla lista dando il loro
assenso. (Questa politica si applica alle zucche attuali e precedenti, così come ad altre
committenti.)

Possono essere invece utilizzati altri meccanismi di voto, purché lo stesso numero di voti sia
raccolti in modo trasparente. Nello specifico, proposte di cui modifiche a cherry-pick
deve essere visibile a tutti su perl5-porters in modo che le opinioni di tutti gli interessati possano
essere ascoltato.

Non è necessario che la votazione si tenga sulle voci perldelta di cherry-picking associate
con modifiche che sono già state selezionate, né per il maint-pumping da ottenere
voti sulle modifiche richieste dal Porting/release_managers_guide.pod dove tali cambiamenti possono
essere applicato mediante cherry-picking da blead.

HA CONTRIBUITO MODULI

A Social Contratto circa Artistico Controllo
Quella che segue è una dichiarazione sul controllo artistico, definito come la capacità degli autori di
pacchetti per guidare il futuro del loro codice e mantenere il controllo sul loro lavoro. È un
riconoscimento che gli autori dovrebbero avere il controllo sul loro lavoro, e che è un
responsabilità del resto della comunità Perl di assicurarsi che mantengano questo controllo.
È un tentativo di documentare gli standard a cui noi, come sviluppatori Perl, intendiamo attenerci
noi stessi. È un tentativo di scrivere linee guida approssimative sul rispetto che dobbiamo a ciascuno
altri come sviluppatori Perl.

Questa dichiarazione non è un contratto legale. Questa dichiarazione non è un documento legale in nessun
modo, forma o forma. Perl è distribuito sotto la GNU Public License e sotto il
Licenza Artistica; questi sono i termini legali precisi. Questa affermazione non riguarda la legge
o licenze. Si tratta di comunità, rispetto reciproco, fiducia e cooperazione in buona fede.

Riconosciamo che il core Perl, definito come il software distribuito con il cuore di
Perl stesso, è un progetto comune da parte di tutti noi. Di tanto in tanto, un copione,
modulo, o insieme di moduli (di seguito denominato semplicemente "modulo") si dimostrerà così
ampiamente utile e/o talmente parte integrante del corretto funzionamento di Perl stesso che dovrebbe
essere distribuito con il core Perl. Questo non dovrebbe mai essere fatto senza l'autore
consenso esplicito, e un chiaro riconoscimento da tutte le parti che questo significa che il modulo è in corso
distribuito negli stessi termini del Perl stesso. L'autore di un modulo dovrebbe rendersene conto
l'inclusione di un modulo nel core Perl significherà necessariamente una perdita di controllo su
it, poiché occasionalmente potrebbe essere necessario apportare modifiche con breve preavviso o per coerenza con
il resto di Perl.

Tuttavia, una volta che un modulo è stato incluso nel core Perl, tutti coloro che sono coinvolti in
mantenere Perl dovrebbe essere consapevole che il modulo è ancora di proprietà dell'originale
autore a meno che l'autore originale non ceda esplicitamente la sua proprietà. In
particolare:

· La versione del modulo nel core Perl dovrebbe ancora essere considerata il lavoro del
autore originale. Tutte le patch, le segnalazioni di bug e così via dovrebbero essere restituite a loro.
Le loro direzioni di sviluppo dovrebbero essere rispettate ove possibile.

· I cerotti possono essere applicati dal detentore della zucca senza l'esplicita collaborazione del
autore del modulo se e solo se sono molto minori, in qualche modo critici in termini di tempo (come
come correzioni di sicurezza urgenti), o se l'autore del modulo non può essere raggiunto. quelle patch
deve comunque essere restituito all'autore quando possibile, e se l'autore decide su un
correzione alternativa nella loro versione, quella correzione dovrebbe essere fortemente preferita a meno che non ci sia
un problema serio con esso. Eventuali modifiche non approvate dall'autore devono essere contrassegnate come
tale, e il contributore del cambiamento riconosciuto.

· La versione del modulo distribuito con Perl dovrebbe, quando possibile, essere la
ultima versione del modulo distribuita dall'autore (l'ultima versione non beta
nel caso di versioni pubbliche di Perl), anche se il possessore di zucca può resistere
aggiornare la versione del modulo distribuito con Perl all'ultima versione fino a
l'ultima versione ha avuto test sufficienti.

In altre parole, si dovrebbe ritenere che l'autore di un modulo abbia l'ultima parola su
modifiche al loro modulo quando possibile (tenendo presente che è previsto che
tutte le persone coinvolte lavoreranno insieme e arriveranno a compromessi ragionevoli quando ce ne saranno
disaccordi).

Come ultima risorsa, tuttavia:

Se la visione dell'autore del futuro del proprio modulo è sufficientemente diversa dalla
visione del portazucca e dei perl5-porters nel loro insieme in modo da causare seri problemi
per Perl, il possessore di zucca può scegliere di biforcare formalmente la versione del modulo nel
Core Perl da quello mantenuto dall'autore. Questo non dovrebbe essere fatto alla leggera e
dovrebbero sempre se possibile essere fatto solo dopo un input diretto da Larry. Se questo è
fatto, deve poi essere reso esplicito nel modulo come distribuito con il core Perl che
è una versione biforcuta e, sebbene sia basata sul lavoro dell'autore originale, non lo è
più mantenuti da loro. Questo deve essere annotato sia nella documentazione che nel
commenti nel sorgente del modulo.

Ancora una volta, questa dovrebbe essere solo l'ultima risorsa. Idealmente, questo non dovrebbe mai accadere, e ogni
prima di fare ciò, dovrebbero essere compiuti possibili sforzi di cooperazione e di compromesso. se è
si rivela necessario creare un modulo per la salute generale di Perl, un credito adeguato deve
essere dato all'autore originale in perpetuo e la decisione dovrebbe essere costantemente ri-
valutata per vedere se è possibile un riavvicinamento dei due rami lungo la strada.

In tutti i rapporti con i moduli forniti, chiunque mantenga Perl dovrebbe tenere a mente
che il codice appartiene all'autore originale, che potrebbero non essere mai su perl5-porter
dato il tempo, e che una patch non è ufficiale a meno che non sia stata integrata nel
copia dell'autore del modulo. Per aiutare con questo, e con i punti #1, #2 e #3 sopra,
le informazioni di contatto per gli autori di tutti i moduli forniti devono essere conservate con il
Distribuzione Perla.

Infine, la comunità Perl nel suo insieme riconosce che il rispetto per la proprietà del codice,
rispetto per il controllo artistico, credito adeguato e impegno attivo per prevenire non intenzionali
l'inclinazione del codice o le lacune nella comunicazione è vitale per la salute della comunità e per lo stesso Perl.
I membri di una comunità normalmente non dovrebbero dover ricorrere a regole e leggi per affrontarli
tra loro, e questo documento, sebbene contenga regole per intenderci, riguarda un
atteggiamento e approccio generale. Il primo passo in ogni controversia dovrebbe essere aperto
comunicazione, rispetto per opinioni opposte e tentativo di compromesso. in quasi
ogni circostanza nulla di più sarà necessario, e certamente nessuna misura più drastica
dovrebbe essere utilizzato fino a quando ogni via di comunicazione e discussione non sia fallita.

DOCUMENTAZIONE

La documentazione di Perl è una risorsa importante per i nostri utenti. È incredibilmente importante per
La documentazione di Perl deve essere ragionevolmente coerente e riflettere accuratamente l'attuale
attuazione.

Proprio come P5P mantiene collettivamente la base di codice, manteniamo collettivamente la
documentazione. Scrivere un particolare pezzo di documentazione non dà il controllo all'autore
del futuro di quella documentazione. Allo stesso tempo, proprio come dovrebbero fare le modifiche al codice sorgente
corrispondono allo stile dei blocchi circostanti, così la documentazione dovrebbe cambiare.

Gli esempi nella documentazione dovrebbero essere illustrativi del concetto che stanno spiegando.
A volte, il modo migliore per mostrare come funziona una funzione linguistica è con un piccolo programma che
il lettore può essere eseguito senza modifiche. Più spesso, gli esempi consisteranno in un frammento di
codice contenente solo i bit "importanti". La definizione di "importante" varia da
frammento per frammento. A volte è importante dichiarare "use strict" e "use warnings",
inizializza tutte le variabili e cattura completamente ogni condizione di errore. Più spesso che non,
tuttavia, queste cose oscurano la lezione che l'esempio intendeva insegnare.

Poiché Perl è sviluppato da un team globale di volontari, la nostra documentazione spesso contiene
ortografie che sembrano divertenti qualcuno. La scelta dell'ortografia americana/britannica/altre è
lasciato come esercizio per l'autore di ogni bit di documentazione. Quando si applica la patch
documentazione, prova a emulare la documentazione intorno a te, piuttosto che cambiare il
prosa esistente.

In generale, la documentazione dovrebbe descrivere cosa fa Perl "adesso" piuttosto che cosa faceva prima
fare. È perfettamente ragionevole includere note nella documentazione su come si è comportato il comportamento
è cambiato rispetto alle versioni precedenti, ma, con pochissime eccezioni, la documentazione non è "dual-
life" - non ha bisogno di descrivere completamente come funzionavano tutte le vecchie versioni.

STANDARD OF CONDOTTA

Il forum ufficiale per lo sviluppo di perl è la mailing list perl5-porters,
menzionato sopra, e il suo bugtracker su rt.perl.org. Tutti i partecipanti in discussione lì
ci si aspetta che aderiscano a uno standard di condotta.

· Sii sempre civile.

· Ascolta i moderatori.

La civiltà è semplice: attenersi ai fatti evitando commenti umilianti e sarcasmo. Esso
non è sufficiente per essere reali. Devi anche essere civile. Rispondere in modo gentile all'inciviltà è
non accettabile.

Mentre è richiesta la civiltà, la gentilezza è incoraggiata; se hai qualche dubbio sul fatto che
sei civile, chiediti semplicemente: "Sono gentile?" e aspirare a questo.

Se i moderatori della lista ti dicono che non sei civile, considera attentamente come il tuo
le parole sono apparse prima di rispondere in alcun modo. sono stati gentili? Puoi protestare, ma
non sono ammesse proteste ripetute di fronte a una decisione ripetutamente ribadita.

Un comportamento inaccettabile risulterà in un avviso pubblico e chiaramente identificato. ripetuto
comportamento inaccettabile comporterà la rimozione dalla mailing list e la revoca di
diritti di aggiornamento rt.perl.org. La prima rimozione è per un mese. Rimozioni successive
raddoppierà in lunghezza. Dopo sei mesi senza preavviso, la durata del divieto di un utente viene reimpostata.
Le rimozioni, come gli avvisi, sono pubbliche.

L'elenco dei moderatori sarà di dominio pubblico. Attualmente sono: Aaron Crane, Andy
Dougherty, Ricardo Signes, Steffen Mueller.

CREDITS

"Contratto sociale sui moduli contributivi" originariamente di Russ Allbery[email protected]>
e i perl5-porter.

Usa perlpolicy online utilizzando i servizi onworks.net