CONTENUTI

  • NOME
  • DESCRIZIONE
  • GOVERNO
    • Perl 5 Facchini
  • MANUTENZIONE E SUPPORTO
  • COMPATIBILITÀ ALL'INDIETRO E DEPREZZAMENTO
    • Terminologia
  • RAMI DI MANUTENZIONE
    • Inserire le modifiche in un ramo di manutenzione
  • MODULI CONTRIBUITI
    • Un contratto sociale sul controllo artistico
  • DOCUMENTAZIONE
  • NORME DI COMPORTAMENTO
  • CREDITI

NOME

perlpolicy - Politiche e impegni vari e diversi relativi al nucleo del Perl

DESCRIZIONE

Questo documento è il documento principale che registra tutte le politiche scritte su come i portatori di Perl 5 sviluppano e mantengono collettivamente il nucleo del Perl.

GOVERNANCE

Portatori di Perl 5

Gli abbonati a perl5-porters (i portatori stessi) sono di diversi tipi. Alcuni sono curiosi e tranquilli, che raramente intervengono e guardano invece lo sviluppo in corso per assicurarsi di essere avvertiti dei nuovi cambiamenti o delle nuove funzionalità del Perl. Alcuni sono rappresentanti dei fornitori, che si assicurano che il Perl continui a essere compilato e a funzionare sulle loro piattaforme. Alcuni correggono qualsiasi bug segnalato che sanno come risolvere, altri si occupano attivamente di correggere le loro aree preferite (thread, Win32, il motore regexp), mentre altri sembrano non fare altro che lamentarsi. In altre parole, è il solito mix di tecnici.

Su questo gruppo di portinai presiede Larry Wall. È lui che ha l'ultima parola su ciò che cambia e non cambia nei linguaggi di programmazione Perl. In questi giorni, Larry passa la maggior parte del suo tempo su Raku, mentre Perl 5 è guidato da un "pumpking", un porter responsabile di decidere cosa inserire in ogni release e di assicurare che le release avvengano regolarmente.

Larry vede lo sviluppo di Perl come il governo degli Stati Uniti: c'è la legislatura (i portatori), il ramo esecutivo (il -pumpking) e la Corte Suprema (Larry). La legislatura può discutere e presentare patch al ramo esecutivo quanto vuole, ma il ramo esecutivo è libero di porre il veto. Raramente, la Corte Suprema si schiera con il ramo esecutivo a scapito della legislatura o con la legislatura a scapito del ramo esecutivo. Nella maggior parte dei casi, tuttavia, il ramo legislativo e quello esecutivo dovrebbero andare d'accordo e risolvere le loro differenze senza impeachment o cause giudiziarie.

A volte si può vedere un riferimento all'articolo 1 e all'articolo 2. Il potere di Larry come Corte Suprema è espresso nel Regolamento:

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

  2. Larry può cambiare idea su qualsiasi questione in un secondo momento, indipendentemente dal fatto che abbia precedentemente invocato la regola 1.

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

MANUTENZIONE E SUPPORTO

Perl 5 è sviluppato da una comunità, non da un'entità aziendale. Ogni modifica apportata al nucleo del Perl è il risultato di una donazione. In genere, queste donazioni sono contributi di codice o di tempo da parte di singoli membri della comunità. A volte, queste donazioni si presentano sotto forma di sponsorizzazione aziendale o organizzativa di un particolare individuo o progetto.

Essendo un'organizzazione di volontari, gli impegni che prendiamo dipendono fortemente dalla buona volontà e dal duro lavoro di individui che non hanno alcun obbligo di contribuire a Perl.

Detto questo, apprezziamo la stabilità e la sicurezza del Perl e da tempo abbiamo stretto un patto non scritto con la comunità del Perl in generale per supportare e mantenere le versioni del Perl.

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

  • Supportiamo "ufficialmente" le due serie di release stabili più recenti. Le versioni 5.26.x e precedenti non sono più supportate. A partire dal rilascio della versione 5.32.0, termineremo "ufficialmente" il supporto per Perl 5.28.x, a parte la fornitura di aggiornamenti di sicurezza come descritto di seguito.

  • Per quanto possibile, cercheremo di risolvere i problemi critici nelle due più recenti serie di release 5.x stabili. Le correzioni per la serie di release corrente hanno la precedenza su quelle per la serie di release precedente.

  • Per quanto possibile, forniremo patch/rilasci di sicurezza "critici" per qualsiasi versione principale di Perl il cui rilascio 5.x.0 sia avvenuto negli ultimi tre anni. Possiamo impegnarci a fornire queste patch solo per la versione .y più recente di qualsiasi serie 5.x.y.

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

  • Incoraggiamo i fornitori a distribuire la più recente versione di Perl supportata al momento del loro code freeze.

  • In qualità di venditori, potreste avere l'esigenza di eseguire il backport delle correzioni di sicurezza oltre i nostri 3 anni di supporto. Possiamo fornirvi un supporto e una consulenza limitati in tal senso e, ove possibile, cercheremo di applicare tali patch ai rami -maint di git, anche se potremmo decidere di rendere disponibili release numerate o patch "ufficiali". Vedere "INFORMAZIONI DI CONTATTO SULLA VULNERABILITÀ DELLA SICUREZZA" in perlsec per i dettagli su come iniziare questo processo.

COMPATIBILITÀ ALL'INDIETRO E DEPREZZAMENTO

La nostra comunità è da sempre convinta che la retrocompatibilità sia una virtù, anche quando la funzionalità in questione è un difetto di progettazione.

A tutti noi piacerebbe cancellare alcuni errori commessi negli ultimi decenni. Vivere con tutti gli errori di progettazione commessi può portare a una dolorosa stagnazione. Cancellare i nostri errori è molto, molto difficile. Farlo senza danneggiare attivamente i nostri utenti è quasi impossibile.

Ultimamente, ignorare o opporsi attivamente alla compatibilità con le versioni precedenti di Perl è diventato di moda. A volte viene proposta una modifica che vuole usurpare una sintassi che prima aveva un altro significato. A volte, una modifica vuole migliorare una semantica precedentemente impazzita.

In questa strada c'è la follia.

Richiedere ai programmatori utenti finali di cambiare solo alcuni costrutti del linguaggio, anche quelli che nessuno sviluppatore istruito userebbe mai intenzionalmente, equivale a dire "non dovreste passare a una nuova versione di Perl a meno che non abbiate una copertura di test del 100% e possiate fare una verifica manuale completa della vostra base di codice". Se avessimo a disposizione strumenti in grado di aggiornare in modo affidabile il codice sorgente di Perl da una versione all'altra, questa preoccupazione potrebbe essere mitigata in modo significativo.

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

La sintassi e la semantica esistenti dovrebbero essere marcate per la distruzione solo in circostanze molto limitate. Se si ritiene che siano usate molto raramente, se ostacolano un effettivo miglioramento del linguaggio Perl o dell'interprete Perl e se il codice interessato può essere facilmente aggiornato per continuare a funzionare, si può prendere in considerazione la loro rimozione. In caso di dubbio, la prudenza impone di privilegiare la retrocompatibilità. Quando una funzionalità viene deprecata, verrà pubblicata una dichiarazione che descrive il processo decisionale e verrà fornito un collegamento a tale dichiarazione nei documenti perldelta pertinenti.

L'uso di un pragma lessicale per abilitare o disabilitare il comportamento legacy dovrebbe essere preso in considerazione quando appropriato; in assenza di pragma, il comportamento legacy dovrebbe essere abilitato. Quali modifiche retrocompatibili siano controllate implicitamente da un "use v5.x.y" è una decisione che dovrebbe essere presa dal pompaggio in consultazione con la comunità.

Storicamente, ci siamo attenuti a uno standard molto più alto della retrocompatibilità: la compatibilità con i bug. Ogni incidente di implementazione o effetto collaterale involontario dell'esecuzione di un po' di codice è stato considerato una caratteristica del linguaggio da difendere con lo stesso zelo di qualsiasi altra caratteristica o funzionalità. Per quanto frustranti possano essere queste caratteristiche non intenzionali per noi che continuiamo a migliorare il Perl, queste caratteristiche non intenzionali spesso meritano la nostra protezione. È molto importante che il software esistente scritto in Perl continui a funzionare correttamente. Se gli sviluppatori degli utenti finali hanno adottato un bug come caratteristica, dobbiamo trattarlo come tale.

Le nuove sintassi e semantiche che non rompono i costrutti e la sintassi del linguaggio esistente hanno un limite molto più basso. Devono solo dimostrare di essere utili, eleganti, ben progettati e ben testati. Nella maggior parte dei casi, queste aggiunte saranno contrassegnate come sperimentale per qualche tempo. Si veda sotto per maggiori informazioni.

Terminologia

Per essere sicuri che stiamo parlando della stessa cosa quando discutiamo della rimozione di caratteristiche o funzionalità dal nucleo del Perl, abbiamo definizioni specifiche per alcune parole e frasi.

sperimentale

Se qualcosa nel nucleo del Perl è contrassegnato come sperimentale, possiamo cambiare il suo comportamento, deprezzarlo o rimuoverlo senza preavviso. Anche se faremo sempre del nostro meglio per agevolare il percorso di transizione per gli utenti delle funzioni sperimentali, dovreste contattare la mailinglist perl5-porters se trovate utile una funzione sperimentale e volete contribuire a plasmare il suo futuro.

Le caratteristiche sperimentali devono essere sperimentali in due versioni stabili prima di essere contrassegnate come non sperimentali. Le caratteristiche sperimentali saranno revocate solo quando non avranno più bug che modificano la progettazione e quando il loro comportamento sarà rimasto invariato per l'intera durata del ciclo di sviluppo. In altre parole, una caratteristica presente nella v5.20.0 può essere dichiarata non più sperimentale nella v5.22.0 se e solo se il suo comportamento rimane invariato per tutta la durata della v5.21.

deprecato

Se qualcosa nel nucleo del Perl è contrassegnato come deprecato, potremmo rimuoverlo dal nucleo in futuro, anche se potremmo non farlo. In genere, le modifiche incompatibili con il passato avranno avvisi di deprecazione per due cicli di rilascio prima di essere rimosse, ma possono essere rimosse dopo un solo ciclo se il rischio sembra abbastanza basso o i benefici abbastanza alti.

A partire da Perl 5.12, le funzioni e i moduli deprecati avvisano l'utente quando vengono utilizzati. Quando un modulo è deprecato, viene reso disponibile anche su CPAN. Installandolo da CPAN, gli avvisi di deprecazione per quel modulo verranno tacitati.

Se utilizzate una funzione o un modulo deprecato e ritenete che la sua rimozione dal nucleo del Perl sarebbe un errore, contattate la mailinglist perl5-porters e sostenete il vostro caso. Non deprechiamo le cose senza una buona ragione, ma a volte c'è una controargomentazione che non abbiamo considerato. Storicamente, non abbiamo distinto tra funzionalità "deprecate" e "sconsigliate".

sconsigliato

Di tanto in tanto, possiamo contrassegnare i costrutti e le caratteristiche del linguaggio che consideriamo essere stati degli errori come sconsigliati. Le caratteristiche sconsigliate non sono attualmente candidate alla rimozione, ma potremmo in seguito deprecarle se dovessero risultare d'intralcio a un miglioramento significativo del nucleo del Perl.

rimosso

Una volta che una funzione, un costrutto o un modulo è stato contrassegnato come deprecato, possiamo rimuoverlo dal nucleo del Perl. Non sorprende che si dica che abbiamo rimosso queste cose. Quando un modulo viene rimosso, non sarà più fornito con Perl, ma continuerà a essere disponibile su CPAN.

RAMI DI MANUTENZIONE

I nuovi rilasci dei rami di manutenzione devono contenere solo modifiche che rientrano in una delle categorie "accettabili" indicate di seguito, ma non devono contenere modifiche che rientrano in una delle categorie "inaccettabili". (Ad esempio, la correzione di un bug di crash non deve essere inclusa se rompe la compatibilità binaria).

Non è necessario includere tutte le modifiche che soddisfano questi criteri, e in generale l'attenzione dovrebbe essere rivolta alla risoluzione di problemi di sicurezza, bug di crash, regressioni e gravi problemi di installazione. La tentazione di includere una pletora di modifiche minori che non influiscono sull'installazione o sull'esecuzione del perl (ad esempio correzioni ortografiche nella documentazione) dovrebbe essere contrastata per ridurre il rischio complessivo di trascurare qualcosa. L'intenzione è quella di creare release di manutenzione che siano utili e di cui gli utenti possano avere piena fiducia nella stabilità. (Una preoccupazione secondaria è quella di evitare di bruciare il maint-pumpking o di sopraffare gli altri committer che votano sulle modifiche da includere (si veda "Ottenere le modifiche in un ramo di maint" più avanti).

I seguenti tipi di modifiche possono essere considerati accettabili, purché non rientrino anche in una delle categorie "inaccettabili" indicate di seguito:

  • Patch che correggono CVE o problemi di sicurezza. Queste modifiche dovrebbero essere passate utilizzando il meccanismo di segnalazione della sicurezza piuttosto che applicate direttamente; vedere "INFORMAZIONI DI CONTATTO SULLA VULNERABILITÀ DELLA SICUREZZA" in perlsec.

  • Patch che correggono bug di crash, fallimenti di asserzioni e corruzione della memoria, ma che non cambiano la funzionalità di perl o non hanno un impatto negativo sulle prestazioni.

  • Le patch che correggono le regressioni nel comportamento del perl rispetto alle versioni precedenti, a prescindere dall'età della regressione, poiché alcune persone possono aggiornare da versioni molto vecchie di perl alla versione più recente.

  • Le patch che correggono i bug delle funzioni che erano nuove nella corrispondente release stabile 5.x.0.

  • Le patch che correggono qualsiasi cosa che impedisca o influenzi seriamente la compilazione o l'installazione di perl.

  • Correzioni alla portabilità, come le modifiche a Configure e ai file della cartella hints/.

  • Patch minime che correggono i fallimenti dei test specifici della piattaforma.

  • Aggiornamenti della documentazione che correggono errori di fatto, spiegano bug significativi o carenze nell'implementazione corrente o correggono markup non funzionanti.

  • Gli aggiornamenti ai moduli dual-life dovrebbero consistere in patch minime per correggere bug di crash o problemi di sicurezza (come sopra). Qualsiasi modifica apportata ai moduli dual-life per i quali CPAN è canonico deve essere coordinata con l'autore upstream.

I seguenti tipi di modifiche NON sono accettabili:

  • Le patch che rompono la compatibilità binaria. (Si prega di parlare con una zucca).

  • Patch che aggiungono o rimuovono funzionalità.

  • Patch che aggiungono nuovi avvertimenti o errori o deprecano funzionalità.

  • Porti di Perl a una nuova piattaforma, architettura o versione del sistema operativo che comportano modifiche all'implementazione.

  • Le nuove versioni di moduli a doppia vita NON devono essere importate in maint. Queste appartengono alla serie stabile successiva.

Se c'è qualche dubbio sul fatto che una determinata patch possa meritare di essere inclusa in una release di maint, allora quasi certamente non dovrebbe essere inclusa.

Portare le modifiche in un ramo maint

Storicamente, solo la zucca raccoglieva le modifiche da bleadperl a maintperl. Questo ha problemi di scalabilità. Allo stesso tempo, i rami di manutenzione delle versioni stabili del Perl devono essere trattati con grande attenzione. A questo scopo, a partire da Perl 5.12, abbiamo un nuovo processo per i rami di manutenzione.

Ogni commit può scegliere di trasferire qualsiasi commit da blead a un ramo di maint aggiungendo prima una voce al file di votazione pertinente nel ramo maint-votes, annunciando il commit come candidato al back-porting, e poi aspettando che almeno altri due commit aggiungano i loro voti a sostegno (cioè è necessario un totale di almeno tre voti prima che un commit possa essere back-portato).

La maggior parte del lavoro di raccolta di un insieme adeguato di commit candidati e di selezione di quelli per i quali sono stati espressi tre voti sarà svolto dal release manager del ramo maint, ma chiunque altro è libero di aggiungere altre proposte se vuole assicurarsi che certe correzioni non vengano trascurate o se teme che lo siano già state.

Possono essere utilizzati anche altri meccanismi di voto (ad esempio l'invio di una mail a perl5-porters e almeno altri due committer che rispondano alla lista dando il loro assenso), purché venga raccolto lo stesso numero di voti in modo trasparente. In particolare, le proposte di quali modifiche scegliere devono essere visibili a tutti su perl5-porters, in modo da poter ascoltare le opinioni di tutti gli interessati.

Non è necessario che si voti per il cherry-picking delle voci di perldelta associate a modifiche che sono già state cherry-pickate, né che il maint-pumpking ottenga voti sulle modifiche richieste dalla direttiva Porting/release_managers_guide.pod dove tali modifiche possono essere applicate con il metodo del cherry-picking da blead.

MODULI CONTRIBUITI

Un contratto sociale sul controllo artistico

Quella che segue è una dichiarazione sul controllo artistico, definito come la capacità degli autori di pacchetti di guidare il futuro del loro codice e di mantenere il controllo sul loro lavoro. È un riconoscimento del fatto che gli autori dovrebbero avere il controllo sul loro lavoro e che è responsabilità del resto della comunità Perl assicurare che essi mantengano questo controllo. È un tentativo di documentare gli standard a cui noi, come sviluppatori Perl, intendiamo attenerci. È un tentativo di scrivere delle linee guida di massima sul rispetto che ci dobbiamo reciprocamente come sviluppatori Perl.

Questa dichiarazione non è un contratto legale. Questa dichiarazione non è un documento legale in alcun modo, forma o modo. Il Perl è distribuito sotto la Licenza Pubblica GNU e sotto le Licenze Artistiche.e; Questi sono i termini legali precisi. Questa dichiarazione non riguarda la legge o le licenze. Riguarda la comunità, il rispetto reciproco, la fiducia e la cooperazione in buona fede.

Riconosciamo che il nucleo del Perl, definito come il software distribuito con il cuore del Perl stesso, è un progetto comune da parte di tutti noi. Di tanto in tanto, uno script, un modulo o un insieme di moduli (di seguito indicato semplicemente come "modulo") si rivelerà così ampiamente utile e/o così parte integrante del corretto funzionamento del Perl stesso da dover essere distribuito con il nucleo del Perl. Questo non dovrebbe mai essere fatto senza il consenso esplicito dell'autore e senza un chiaro riconoscimento da parte di tutti che ciò significa che il modulo viene distribuito alle stesse condizioni del Perl stesso. L'autore di un modulo dovrebbe rendersi conto che l'inclusione di un modulo nel nucleo del Perl implica necessariamente una certa perdita di controllo su di esso, dal momento che occasionalmente potrebbe essere necessario apportare modifiche con breve preavviso o per coerenza con il resto del Perl.

Una volta che un modulo è stato incluso nel nucleo del Perl, tuttavia, tutti coloro che sono coinvolti nella manutenzione del Perl dovrebbero essere consapevoli che il modulo è ancora di proprietà dell'autore originale, a meno che quest'ultimo non rinunci esplicitamente alla sua proprietà. In particolare:

  • La versione del modulo presente nel nucleo del Perl deve essere ancora considerata il lavoro dell'autore originale. Tutte le patch, le segnalazioni di bug e così via devono essere trasmesse all'autore. Le loro direzioni di sviluppo devono essere rispettate quando possibile.

  • Le patch possono essere applicate dal detentore della zucca senza l'esplicita collaborazione dell'autore del modulo se e solo se sono molto piccole, critiche per il tempo (come le correzioni urgenti per la sicurezza), o se l'autore del modulo non può essere raggiunto. Tali patch devono comunque essere restituite all'autore, quando possibile, e se l'autore decide di inserire una correzione alternativa nella propria versione, tale correzione dovrebbe essere fortemente preferita, a meno che non ci sia un problema serio. Qualsiasi modifica non approvata dall'autore dovrebbe essere segnalata come tale e il contributore della modifica dovrebbe essere riconosciuto.

  • La versione del modulo distribuita con il Perl dovrebbe essere, quando possibile, l'ultima versione del modulo distribuita dall'autore (l'ultima versione non beta nel caso di versioni pubbliche del Perl), anche se il detentore della zucca può aspettare ad aggiornare la versione del modulo distribuita con il Perl all'ultima versione fino a quando quest'ultima non sia stata testata a sufficienza.

In altre parole, si dovrebbe ritenere che l'autore di un modulo abbia l'ultima parola sulle modifiche al proprio modulo, quando possibile (tenendo presente che ci si aspetta che tutti i soggetti coinvolti lavorino insieme e arrivino a compromessi ragionevoli in caso di disaccordo).

Come ultima risorsa, tuttavia:

Se la visione dell'autore sul futuro del suo modulo è sufficientemente diversa da quella del detentore della zucca e dei portatori di perl5 nel loro complesso, in modo da causare seri problemi al Perl, il detentore della zucca può scegliere di fare un fork formale della versione del modulo nel nucleo del Perl da quella mantenuta dall'autore. Questo non dovrebbe essere fatto con leggerezza e dovrebbe sempre se possibile, essere fatto solo dopo un input diretto da parte di Larry. Se ciò viene fatto, nel modulo distribuito con il nucleo del Perl deve essere esplicitamente indicato che si tratta di una versione biforcuta e che, pur essendo basata sul lavoro dell'autore originale, non è più mantenuta da quest'ultimo. Questo deve essere segnalato sia nella documentazione che nei commenti del sorgente del modulo.

Ancora una volta, questa dovrebbe essere solo l'ultima risorsa. Idealmente, questo non dovrebbe mai accadere e prima di farlo si dovrebbe fare ogni possibile sforzo di cooperazione e compromesso. Se si rivela necessario fare un fork di un modulo per la salute generale del Perl, deve essere dato il giusto credito all'autore originale in perpetuo e la decisione deve essere costantemente rivalutata per vedere se è possibile una riemersione dei due rami in futuro.

In tutti i rapporti con i moduli contribuiti, tutti coloro che mantengono il Perl dovrebbero tenere a mente che il codice appartiene all'autore originale, che potrebbe non essere presente su perl5-porter in un dato momento e che una patch non è ufficiale a meno che non sia stata integrata nella copia del modulo dell'autore. Per aiutare questo, e per i punti #1, #2 e #3 di cui sopra, le informazioni di contatto per gli autori di tutti i moduli contribuiti dovrebbero essere conservate nella distribuzione del Perl.

Infine, la comunità Perl nel suo complesso riconosce che il rispetto per la proprietà del codice, il rispetto per il controllo artistico, il credito adeguato e lo sforzo attivo per prevenire involontarie distorsioni del codice o lacune nella comunicazione sono vitali per la salute della comunità e del Perl stesso. I membri di una comunità non dovrebbero normalmente ricorrere a regole e leggi per trattare gli uni con gli altri, e questo documento, sebbene contenga regole in modo da essere chiaro, riguarda un atteggiamento e un approccio generale. Il primo passo in ogni controversia dovrebbe essere una comunicazione aperta, il rispetto dei punti di vista opposti e un tentativo di compromesso. In quasi tutte le circostanze non sarà necessario altro, e certamente non si dovrà ricorrere a misure più drastiche prima che ogni via di comunicazione e discussione sia fallita.

DOCUMENTAZIONE

La documentazione del Perl è una risorsa importante per i nostri utenti. È incredibilmente importante che la documentazione del Perl sia ragionevolmente coerente e rifletta accuratamente l'implementazione corrente.

Così come P5P mantiene collettivamente la base di codice, noi manteniamo collettivamente la documentazione. Scrivere un particolare pezzo di documentazione non dà all'autore il controllo del futuro di quella documentazione. Allo stesso tempo, proprio come le modifiche al codice sorgente dovrebbero essere in linea con lo stile dei blocchi circostanti, così dovrebbero essere le modifiche alla documentazione.

Gli esempi nella documentazione dovrebbero essere illustrativi del concetto che stanno spiegando. A volte, il modo migliore per mostrare il funzionamento di una caratteristica del linguaggio è un piccolo programma che il lettore può eseguire senza modifiche. Più spesso, gli esempi consistono in un frammento di codice contenente solo le parti "importanti". La definizione di "importante" varia da frammento a frammento. A volte è importante dichiarare use strict e use warnings, inizializzare tutte le variabili e catturare completamente ogni condizione di errore. Il più delle volte, però, queste cose oscurano la lezione che l'esempio intendeva impartire.

Poiché Perl è sviluppato da un team globale di volontari, la nostra documentazione contiene spesso delle ortografie che sembrano strane a qualcuno. La scelta di ortografie americane/britanniche/altre è lasciata come esercizio all'autore di ciascuna documentazione. Quando si modifica la documentazione, cercare di emulare la documentazione circostante, piuttosto che cambiare la prosa esistente.

In generale, la documentazione dovrebbe descrivere ciò che il Perl fa "ora" piuttosto che ciò che faceva prima. È perfettamente ragionevole includere nella documentazione note su come il comportamento è cambiato rispetto alle versioni precedenti, ma, salvo rare eccezioni, la documentazione non è "a doppia vita": non ha bisogno di descrivere completamente come funzionavano tutte le vecchie versioni.

NORME DI COMPORTAMENTO

Il forum ufficiale per lo sviluppo di perl è la mailing list perl5-porters, menzionata sopra, e il suo bugtracker su GitHub. Postare sulla lista e sul bugtracker non è un diritto: tutti i partecipanti alla discussione sono tenuti ad aderire a uno standard di condotta.

  • Siate sempre civili.

  • Ascoltate i moderatori.

La civiltà è semplice: attenersi ai fatti evitando commenti svilenti, sminuendo altri individui, sarcasmo o presunzione di malafede. Non è sufficiente essere concreti. Bisogna anche essere civili. Rispondere in modo gentile all'inciviltà non è accettabile. Se si trasmettono alla lista commenti non pubblicati da terzi, ci si assume la responsabilità del contenuto di tali commenti e si deve quindi garantire che siano civili.

Mentre la civiltà è richiesta, la gentilezza è incoraggiata.ed; Se avete dei dubbi sul vostro comportamento civile, chiedetevi semplicemente: "Sono gentile?" e aspirate a questo.

Se i moderatori della lista vi dicono che non vi state comportando in modo civile, considerate attentamente come sono apparse le vostre parole prima di rispondere in qualsiasi modo. Sono state gentili? Potete protestare, ma non è accettabile una protesta ripetuta di fronte a una decisione ribadita più volte. Anche protestare ripetutamente per le decisioni dei moderatori in merito a terzi è inaccettabile, così come continuare a contattare i moderatori fuori dalla lista in merito alle loro decisioni.

Un comportamento inaccettabile comporterà un avvertimento pubblico e chiaramente identificato. Un secondo caso di comportamento inaccettabile da parte dello stesso individuo comporterà la rimozione dalla mailing list e dal tracker dei problemi di GitHub, per un periodo di un mese di calendario. Il motivo di questa decisione è di dare alla persona l'opportunità di cambiare il proprio modo di agire.

Dopo la revoca del divieto a tempo determinato, un terzo caso di comportamento inaccettabile comporterà un ulteriore avvertimento pubblico. Un quarto o successivo caso comporterà un divieto a tempo indeterminato. La logica è che, di fronte a un apparente rifiuto di cambiare comportamento, dobbiamo proteggere gli altri membri della comunità da future azioni inaccettabili. I moderatori possono decidere di revocare un divieto a tempo indeterminato se la persona in questione afferma che non trasgredirà di nuovo.

Le rimozioni, come gli avvertimenti, sono pubbliche.

L'elenco dei moderatori sarà di dominio pubblico. Attualmente è composta da: Andy Dougherty, Karen Etheridge, Ricardo Signes, Sawyer X, Steffen Müller, Todd Rinaldo, Aaron Crane.

CREDITI

"Contratto sociale sui moduli forniti" originariamente di Russ Allbery <[email protected]> e dai portatori di perl5.