CONTENU

  • NOM
  • DESCRIPTION
  • GOUVERNANCE
    • Porters Perl 5
  • MAINTENANCE ET SUPPORT
  • COMPATIBILITÉ ASCENDANTE ET DÉPRÉCIATION
    • Terminologie
  • BRANCHES DE MAINTENANCE
    • Obtenir des modifications dans une branche de maintenance
  • MODULES CONTRIBUÉS
    • Un contrat social sur le contrôle artistique
  • DOCUMENTATION
  • NORMES DE CONDUITE
  • CREDITS

NOM

perlpolicy - Politiques et engagements divers et variés liés au noyau Perl.

DESCRIPTION

Ce document est le document maître qui enregistre toutes les politiques écrites sur la façon dont les porteurs de Perl 5 développent et maintiennent collectivement le noyau Perl.

GOUVERNANCE

Perl 5 Porters

Les abonnés à perl5-porters (les porteurs eux-mêmes) sont de plusieurs sortes. Certains sont des curieux discrets, qui ne participent que rarement et observent plutôt le développement en cours pour s'assurer qu'ils sont prévenus des nouveaux changements ou des nouvelles fonctionnalités de Perl. D'autres sont des représentants de vendeurs, qui sont là pour s'assurer que Perl continue à compiler et à fonctionner sur leurs plateformes. Certains corrigent tous les bogues signalés qu'ils savent corriger, d'autres corrigent activement leur domaine de prédilection (threads, Win32, le moteur de regexp), tandis que d'autres encore semblent ne faire que se plaindre. En d'autres termes, c'est votre mélange habituel de personnes techniques.

Larry Wall préside ce groupe de porteurs. C'est lui qui a le dernier mot sur ce qui change ou non dans les langages de programmation Perl. Ces jours-ci, Larry passe la plupart de son temps sur Raku, tandis que Perl 5 est guidé par un "pumpking", un porteur responsable de décider ce qui va dans chaque version et de s'assurer que les versions se produisent sur une base régulière.

Larry voit le développement de Perl sur le modèle du gouvernement américain : il y a le pouvoir législatif (les porteurs), le pouvoir exécutif (le -pumpking), et la Cour suprême (Larry). Le pouvoir législatif peut discuter et soumettre des correctifs à l'exécutif autant qu'il le souhaite, mais l'exécutif est libre d'y opposer son veto. Il arrive rarement que la Cour suprême prenne le parti de l'exécutif contre le législatif, ou du législatif contre l'exécutif. La plupart du temps, cependant, le pouvoir législatif et le pouvoir exécutif sont censés s'entendre et régler leurs différends sans mise en accusation ni procès.

Vous pouvez parfois voir une référence à la règle 1 et à la règle 2. Le pouvoir de Larry en tant que Cour suprême est exprimé dans les règles :

  1. Larry a toujours par définition raison sur la façon dont Perl doit se comporter. Cela signifie qu'il a un droit de veto final sur les fonctionnalités de base.

  2. Larry est autorisé à changer d'avis sur n'importe quel sujet à une date ultérieure, indépendamment du fait qu'il ait précédemment invoqué la règle 1.

Compris ? Larry a toujours raison, même quand il a eu tort. Il est rare de voir l'une ou l'autre règle exercée, mais on y fait souvent allusion.

MAINTENANCE ET SOUTIEN

Perl 5 est développé par une communauté, pas par une entité corporative. Chaque changement apporté au noyau de Perl est le résultat d'un don. Typiquement, ces dons sont des contributions de code ou de temps par des membres individuels de notre communauté. À l'occasion, ces dons prennent la forme d'un parrainage par une entreprise ou une organisation d'une personne ou d'un projet particulier.

En tant qu'organisation bénévole, les engagements que nous prenons dépendent fortement de la bonne volonté et du travail acharné d'individus qui n'ont aucune obligation de contribuer à Perl.

Ceci étant dit, nous apprécions la stabilité et la sécurité de Perl et avons depuis longtemps un pacte non écrit avec la communauté Perl au sens large pour soutenir et maintenir les versions de Perl.

Ce document codifie les engagements de support et de maintenance que la communauté Perl doit attendre des développeurs de Perl :

  • Nous supportons "officiellement" les deux séries de versions stables les plus récentes. Les versions 5.26.x et antérieures ne sont plus supportées. À partir de la sortie de la version 5.32.0, nous mettrons "officiellement" fin au support de Perl 5.28.x, en dehors de la fourniture de mises à jour de sécurité comme décrit ci-dessous.

  • Dans la mesure de nos possibilités, nous tenterons de corriger les problèmes critiques dans les deux séries de versions stables 5.x les plus récentes. Les correctifs de la série de versions actuelle ont la priorité sur les correctifs de la série de versions précédente.

  • Dans la mesure de nos possibilités, nous fournirons des correctifs / versions de sécurité "critiques" pour toute version majeure de Perl dont la version 5.x.0 a été publiée au cours des trois dernières années. Nous ne pouvons nous engager à les fournir que pour la version .y la plus récente de toute série 5.x.y.

  • Nous ne fournirons pas de mises à jour de sécurité ou de corrections de bogues pour les versions de développement de Perl.

  • Nous encourageons les fournisseurs à expédier la plus récente version supportée de Perl au moment de leur gel de code.

  • En tant que fournisseur, vous pouvez avoir besoin de rétrocomporter des correctifs de sécurité au-delà de notre engagement de support de 3 ans. Nous pouvons vous fournir une assistance et des conseils limités pendant que vous le faites et, dans la mesure du possible, nous essaierons d'appliquer ces correctifs aux branches -maint pertinentes dans git, bien que nous puissions choisir ou non de rendre disponibles des versions numérotées ou des correctifs "officiels". Voir "INFORMATIONS DE CONTACT SUR LA VULNÉRABILITÉ DE LA SÉCURITÉ" dans perlsec pour des détails sur la façon de commencer ce processus.

COMPATIBILITÉ ASCENDANTE ET DÉPRÉCIATION

Notre communauté croit depuis longtemps que la rétrocompatibilité est une vertu, même lorsque la fonctionnalité en question est un défaut de conception.

Nous aimerions tous défaire certaines erreurs que nous avons faites au cours des dernières décennies. Vivre avec toutes les erreurs de conception que nous avons faites peut conduire à une stagnation douloureuse. Dénouer nos erreurs est très, très difficile. Le faire sans nuire activement à nos utilisateurs est presque impossible.

Dernièrement, ignorer ou s'opposer activement à la compatibilité avec les versions antérieures de Perl est devenu en vogue. Parfois, un changement est proposé qui veut usurper une syntaxe qui avait auparavant une autre signification. Parfois, un changement veut améliorer une sémantique auparavant farfelue.

En bas de cette route se trouve la folie.

Demander aux programmeurs utilisateurs finaux de changer seulement quelques constructions de langage, même des constructions de langage qu'aucun développeur bien éduqué n'utiliserait jamais intentionnellement revient à dire "vous ne devriez pas passer à une nouvelle version de Perl à moins d'avoir une couverture de test de 100% et de pouvoir faire un audit manuel complet de votre base de code." Si nous disposions d'outils capables de mettre à jour de manière fiable le code source Perl d'une version de Perl à une autre, cette préoccupation pourrait être considérablement atténuée.

Nous voulons nous assurer que Perl continue de croître et de prospérer dans les années et les décennies à venir, mais pas au détriment de notre communauté d'utilisateurs.

La syntaxe et la sémantique existantes ne devraient être marquées pour la destruction que dans des circonstances très limitées. Si l'on pense qu'elles sont très rarement utilisées, qu'elles font obstacle à une amélioration réelle du langage Perl ou de l'interprète perl, et si le code affecté peut être facilement mis à jour pour continuer à fonctionner, on peut envisager de les supprimer. Dans le doute, la prudence nous dicte de privilégier la compatibilité ascendante. Lorsqu'une fonctionnalité est dépréciée, un exposé des motifs décrivant le processus de décision sera publié, et un lien vers celui-ci sera fourni dans les documents perldelta concernés.

L'utilisation d'un pragma lexical pour activer ou désactiver le comportement hérité devrait être envisagée lorsque cela est approprié, et en l'absence de tout pragma, le comportement hérité devrait être activé. Quels changements rétrocompatibles sont contrôlés implicitement par un 'use v5.x.y' est une décision qui devrait être prise par la pompe en consultation avec la communauté.

Historiquement, nous nous sommes tenus à un standard bien plus élevé que la compatibilité ascendante -- la compatibilité descendante. Tout accident d'implémentation ou effet secondaire non intentionnel de l'exécution d'un bout de code a été considéré comme une caractéristique du langage à défendre avec le même zèle que toute autre caractéristique ou fonctionnalité. Peu importe à quel point ces fonctionnalités non intentionnelles peuvent être frustrantes pour nous alors que nous continuons à améliorer Perl, ces fonctionnalités non intentionnelles méritent souvent notre protection. Il est très important que les logiciels existants écrits en Perl continuent à fonctionner correctement. Si les développeurs des utilisateurs finaux ont adopté un bogue comme une fonctionnalité, nous devons le traiter comme tel.

Les nouvelles syntaxes et sémantiques qui ne cassent pas les constructions de langage et la syntaxe existantes ont une barre beaucoup plus basse. Ils doivent simplement prouver qu'ils sont utiles, élégants, bien conçus et bien testés. Dans la plupart des cas, ces ajouts seront marqués en tant que expérimental pendant un certain temps. Voir ci-dessous pour plus d'informations à ce sujet.

Terminologie

Pour s'assurer que nous parlons de la même chose lorsque nous discutons de la suppression de caractéristiques ou de fonctionnalités du noyau Perl, nous avons des définitions spécifiques pour quelques mots et phrases.

expérimental

Si quelque chose dans le noyau Perl est marqué comme expérimental, nous pouvons modifier son comportement, le déprécier ou le supprimer sans préavis. Bien que nous ferons toujours de notre mieux pour faciliter le chemin de transition pour les utilisateurs de fonctionnalités expérimentales, vous devriez contacter la liste de diffusion perl5-porters si vous trouvez une fonctionnalité expérimentale utile et souhaitez aider à façonner son avenir.

Les fonctionnalités expérimentales doivent être expérimentales dans deux versions stables avant d'être marquées comme non expérimentales. Les fonctionnalités expérimentales ne verront leur statut expérimental révoqué que lorsqu'elles n'auront plus de bogues susceptibles de modifier leur conception et que leur comportement sera resté inchangé pendant toute la durée d'un cycle de développement. En d'autres termes, une fonctionnalité présente dans la v5.20.0 peut être marquée comme n'étant plus expérimentale dans la v5.22.0 si et seulement si son comportement est inchangé pendant toute la v5.21.

déprécié

Si quelque chose dans le noyau Perl est marqué comme étant déprécié, nous pourrions le retirer du noyau à l'avenir, mais nous pourrions ne pas le faire. En général, les changements incompatibles avec le passé auront des avertissements de dépréciation pendant deux cycles de publication avant d'être retirés, mais peuvent être retirés après un seul cycle si le risque semble assez faible ou les avantages assez élevés.

À partir de Perl 5.12, les fonctionnalités et modules dépréciés avertissent l'utilisateur lorsqu'ils sont utilisés. Lorsqu'un module est déprécié, il est également mis à disposition sur CPAN. L'installer à partir de CPAN fera taire les avertissements de dépréciation pour ce module.

Si vous utilisez une fonctionnalité ou un module déprécié et que vous pensez que son retrait du noyau Perl serait une erreur, veuillez contacter la liste de diffusion perl5-porters et plaider votre cause. Nous ne déprécions pas les choses sans une bonne raison, mais parfois il y a un contre-argument que nous n'avons pas pris en compte. Historiquement, nous ne faisions pas de distinction entre les fonctionnalités "dépréciées" et "déconseillées".

découragée

De temps en temps, nous pouvons marquer des constructions de langage et des fonctionnalités que nous considérons comme ayant été des erreurs comme. découragées. Les fonctionnalités découragées ne sont pas actuellement candidates à la suppression, mais nous pourrons plus tard les déprécier s'il s'avère qu'elles font obstacle à une amélioration significative du noyau Perl.

supprimé

Une fois qu'une fonctionnalité, une construction ou un module a été marqué comme déprécié, nous pouvons le retirer du noyau Perl. Sans surprise, nous disons que nous avons... supprimé ces choses. Lorsqu'un module est supprimé, il ne sera plus livré avec Perl, mais continuera à être disponible sur CPAN.

BRANCHES DE MAINTENANCE

Les nouvelles versions des branches de maintenance ne doivent contenir que des modifications qui entrent dans l'une des catégories "acceptables" énoncées ci-dessous, mais ne doivent pas contenir de modifications qui entrent dans l'une des catégories "inacceptables". (Par exemple, un correctif pour un bogue de plantage ne doit pas être inclus s'il rompt la compatibilité binaire).

Il n'est pas nécessaire d'inclure chaque changement répondant à ces critères et, en général, l'accent doit être mis sur la résolution des problèmes de sécurité, des bogues de plantage, des régressions et des problèmes d'installation graves. La tentation d'inclure une pléthore de changements mineurs qui n'affectent pas l'installation ou l'exécution de perl (par exemple, des corrections orthographiques dans la documentation) doit être résistée afin de réduire le risque global d'oublier quelque chose. L'intention est de créer des versions de maintenance qui sont à la fois utiles et dont les utilisateurs peuvent avoir une confiance totale dans la stabilité. (Une préoccupation secondaire est d'éviter de griller la maint-pumpking ou de submerger les autres committers votant sur les changements à inclure (voir "Obtenir des changements dans une branche maint" ci-dessous)).

Les types de changements suivants peuvent être considérés comme acceptables, tant qu'ils ne tombent pas également dans l'une des catégories "inacceptables" énoncées ci-dessous :

  • Les correctifs qui corrigent les CVE ou les problèmes de sécurité. Ces changements doivent être transmis en utilisant le mécanisme de rapport de sécurité plutôt que d'être appliqués directement ; voir "INFORMATIONS SUR LES VULNÉRABILITÉS DE SÉCURITÉ" dans perlsec.

  • Les correctifs qui corrigent les bogues de plantage, les échecs d'assertion et la corruption de la mémoire, mais qui ne modifient pas autrement les fonctionnalités de perl ou n'ont pas d'impact négatif sur les performances.

  • Les correctifs qui corrigent les régressions du comportement de perl par rapport aux versions précédentes, quelle que soit l'ancienneté de la régression, car certaines personnes peuvent mettre à niveau de très anciennes versions de perl vers la dernière version.

  • Les correctifs qui corrigent les bogues dans les fonctionnalités qui étaient nouvelles dans la version stable 5.x.0 correspondante.

  • Les correctifs qui corrigent tout ce qui empêche ou affecte sérieusement la construction ou l'installation de perl.

  • Corrections de portabilité, telles que les modifications apportées à Configure et aux fichiers du dossier hints/.

  • Correctifs minimaux qui corrigent les échecs de tests spécifiques à une plateforme.

  • Mises à jour de la documentation qui corrigent les erreurs factuelles, expliquent les bogues ou les déficiences significatives de l'implémentation actuelle, ou corrigent le balisage cassé.

  • Les mises à jour des modules dual-life doivent consister en des correctifs minimaux qui corrigent les bogues de plantage ou les problèmes de sécurité (comme ci-dessus). Toute modification apportée aux modules dual-life pour lesquels CPAN est canonique doit être coordonnée avec l'auteur en amont.

Les types de modifications suivants ne sont PAS acceptables :

  • Les correctifs qui rompent la compatibilité binaire. (Veuillez parler à une citrouille).

  • Les correctifs qui ajoutent ou suppriment des fonctionnalités.

  • Les correctifs qui ajoutent de nouveaux avertissements ou erreurs ou qui déprécient des fonctionnalités.

  • Les ports de Perl vers une nouvelle plate-forme, une nouvelle architecture ou une nouvelle version du système d'exploitation qui impliquent des modifications de l'implémentation.

  • Les nouvelles versions des modules à double vie ne doivent PAS être importées dans maint. Ceux-ci appartiennent à la prochaine série stable.

S'il y a un doute sur le fait qu'un patch donné puisse mériter d'être inclus dans une version maint, alors il ne devrait presque certainement pas être inclus.

Obtenir des changements dans une branche maint.

Historiquement, seule la pompe a cherché les changements de bleadperl dans maintperl. Cela a des problèmes de mise à l'échelle. En même temps, les branches de maintenance des versions stables de Perl doivent être traitées avec beaucoup de soin. À cette fin, à partir de Perl 5.12, nous avons un nouveau processus pour les branches de maintenance.

Tout committer peut choisir n'importe quel commit de blead vers une branche maint en ajoutant d'abord une entrée au fichier de vote correspondant dans la branche maint-votes annonçant le commit comme candidat au rétro-portage, puis en attendant qu'au moins deux autres committers ajoutent leurs votes en faveur de cela (c'est-à-dire qu'un total d'au moins trois votes est requis avant qu'un commit puisse être rétro-porté).

La plupart du travail impliqué à la fois dans l'arrondissement d'un ensemble approprié de commits candidats et dans la sélection de ceux pour lesquels trois votes ont été exprimés sera fait par le responsable de la version de la branche maint, mais n'importe qui d'autre est libre d'ajouter d'autres propositions s'ils sont désireux de s'assurer que certains correctifs ne sont pas négligés ou craignent qu'ils l'aient déjà été.

D'autres mécanismes de vote peuvent également être utilisés à la place (par exemple, l'envoi d'un courrier à perl5-porters et au moins deux autres committers répondant à la liste donnant leur assentiment), tant que le même nombre de votes est recueilli de manière transparente. Plus précisément, les propositions de quels changements à cherry-pick doivent être visibles pour tout le monde sur perl5-porters afin que les opinions de tous les intéressés puissent être entendues.

Il n'est pas nécessaire que le vote soit organisé sur le cherry-picking des entrées perldelta associées à des changements qui ont déjà été cherry-picked, ni que le maint-pumpking obtienne des votes sur les changements requis par le... Portage/release_managers_guide.pod où de tels changements peuvent être appliqués par le moyen du cherry-picking de blead.

MODULES CONTRIBUÉS

Un contrat social sur le contrôle artistique

Ce qui suit est une déclaration sur le contrôle artistique, défini comme la capacité des auteurs de paquets à guider l'avenir de leur code et à maintenir le contrôle sur leur travail. C'est une reconnaissance que les auteurs devraient avoir le contrôle sur leur travail, et qu'il est de la responsabilité du reste de la communauté Perl de s'assurer qu'ils conservent ce contrôle. C'est une tentative de documenter les normes auxquelles nous, en tant que développeurs Perl, avons l'intention de nous tenir. C'est une tentative d'écrire des directives approximatives sur le respect que nous devons les uns aux autres en tant que développeurs Perl.

Cette déclaration n'est pas un contrat légal. Cette déclaration n'est pas un document juridique, de quelque manière que ce soit, sous quelque forme que ce soit. Perl est distribué sous la licence publique GNU et sous les licences artistiques.e; ce sont les termes juridiques précis. Cette déclaration ne concerne pas la loi ou les licences. Il s'agit de communauté, de respect mutuel, de confiance et de coopération de bonne foi.

Nous reconnaissons que le noyau Perl, défini comme le logiciel distribué avec le cœur de Perl lui-même, est un projet commun de la part de chacun d'entre nous. De temps en temps, un script, un module ou un ensemble de modules (ci-après dénommé simplement "module") se révélera si largement utile et/ou si intégré au bon fonctionnement de Perl lui-même qu'il devrait être distribué avec le cœur de Perl. Cela ne devrait jamais être fait sans le consentement explicite de l'auteur, et une reconnaissance claire de toutes les parties que cela signifie que le module est distribué dans les mêmes conditions que Perl lui-même. L'auteur d'un module doit réaliser que l'inclusion d'un module dans le noyau de Perl signifiera nécessairement une certaine perte de contrôle sur celui-ci, puisque des changements peuvent occasionnellement devoir être effectués à court terme ou pour des raisons de cohérence avec le reste de Perl.

Cependant, une fois qu'un module a été inclus dans le noyau de Perl, toutes les personnes impliquées dans la maintenance de Perl doivent être conscientes que le module reste la propriété de l'auteur original, à moins que celui-ci n'en abandonne explicitement la propriété. En particulier :

  • La version du module dans le noyau Perl doit toujours être considérée comme le travail de l'auteur original. Tous les correctifs, rapports de bogues, et ainsi de suite devraient leur être renvoyés. Leurs directions de développement devraient être respectées autant que possible.

  • Les correctifs peuvent être appliqués par le détenteur de la citrouille sans la coopération explicite de l'auteur du module si et seulement s'ils sont très mineurs, s'ils sont critiques en termes de temps d'une certaine manière (comme des correctifs de sécurité urgents), ou si l'auteur du module ne peut être joint. Ces correctifs doivent toujours être rendus à l'auteur lorsque cela est possible, et si l'auteur décide d'un correctif alternatif dans sa version, ce correctif doit être fortement préféré à moins qu'il ne présente un problème sérieux. Toute modification non approuvée par l'auteur doit être marquée comme telle, et le contributeur de la modification reconnu.

  • La version du module distribué avec Perl devrait, dans la mesure du possible, être la dernière version du module telle qu'elle est distribuée par l'auteur (la dernière version non bêta dans le cas des versions publiques de Perl), bien que le détenteur de la citrouille puisse attendre avant de mettre à niveau la version du module distribué avec Perl vers la dernière version jusqu'à ce que celle-ci ait été suffisamment testée.

En d'autres termes, il faut considérer que l'auteur d'un module a le dernier mot sur les modifications de son module dans la mesure du possible (en gardant à l'esprit que l'on s'attend à ce que toutes les personnes impliquées travaillent ensemble et arrivent à des compromis raisonnables en cas de désaccord).

En dernier recours, cependant :

Si la vision de l'auteur sur l'avenir de son module est suffisamment différente de celle du détenteur de la citrouille et des perl5-porters dans leur ensemble pour causer de sérieux problèmes pour Perl, le détenteur de la citrouille peut choisir de bifurquer formellement la version du module dans le noyau Perl de celle maintenue par l'auteur. Cela ne devrait pas être fait à la légère et devrait toujours si possible, être fait seulement après une contribution directe de Larry. Si cela est fait, il faut alors rendre explicite dans le module tel qu'il est distribué avec le noyau Perl qu'il s'agit d'une version bifurquée et que, bien qu'il soit basé sur le travail de l'auteur original, il n'est plus maintenu par lui. Cela doit être noté à la fois dans la documentation et dans les commentaires dans la source du module.

Encore une fois, cela ne devrait être qu'un dernier recours. Idéalement, cela ne devrait jamais arriver, et tous les efforts possibles de coopération et de compromis devraient être faits avant de le faire. S'il s'avère nécessaire de forker un module pour la santé globale de Perl, un crédit approprié doit être donné à l'auteur original à perpétuité et la décision doit être constamment réévaluée pour voir si une re-fusion des deux branches est possible sur la route.

Dans tous les rapports avec les modules contribués, toute personne maintenant Perl devrait garder à l'esprit que le code appartient à l'auteur original, qu'ils peuvent ne pas être sur perl5-porters à un moment donné, et qu'un patch n'est pas officiel tant qu'il n'a pas été intégré dans la copie de l'auteur du module. Pour aider à cela, et aux points #1, #2, et #3 ci-dessus, les coordonnées des auteurs de tous les modules contribués devraient être conservées avec la distribution Perl.

Enfin, la communauté Perl dans son ensemble reconnaît que le respect de la propriété du code, le respect du contrôle artistique, le crédit approprié et l'effort actif pour prévenir les biais de code involontaires ou les lacunes de communication sont essentiels à la santé de la communauté et de Perl lui-même. Les membres d'une communauté ne devraient normalement pas avoir à recourir à des règles et des lois pour traiter les uns avec les autres, et ce document, bien qu'il contienne des règles afin d'être clair, porte sur une attitude et une approche générale. La première étape de tout différend devrait être une communication ouverte, le respect des opinions opposées et une tentative de compromis. Dans presque toutes les circonstances, rien de plus ne sera nécessaire, et certainement aucune mesure plus drastique ne devrait être utilisée avant que toutes les voies de communication et de discussion aient échoué.

DOCUMENTATION

La documentation de Perl est une ressource importante pour nos utilisateurs. Il est incroyablement important pour la documentation de Perl d'être raisonnablement cohérente et de refléter avec précision l'implémentation actuelle.

Tout comme P5P maintient collectivement la base de code, nous maintenons collectivement la documentation. Écrire un bout particulier de documentation ne donne pas à un auteur le contrôle de l'avenir de cette documentation. Dans le même temps, tout comme les modifications du code source doivent correspondre au style des blocs qui les entourent, les modifications de la documentation doivent également correspondre au style de la documentation.

Les exemples dans la documentation doivent être illustratifs du concept qu'ils expliquent. Parfois, la meilleure façon de montrer comment une fonctionnalité du langage fonctionne est avec un petit programme que le lecteur peut exécuter sans modification. Le plus souvent, les exemples consistent en un extrait de code contenant uniquement les éléments "importants". La définition du terme "important" varie d'un extrait à l'autre. Parfois, il est important de déclarer use strict et use warningsd'initialiser toutes les variables et de prendre en compte toutes les conditions d'erreur. Le plus souvent, cependant, ces éléments obscurcissent la leçon que l'exemple était censé enseigner.

Comme Perl est développé par une équipe mondiale de bénévoles, notre documentation contient souvent des orthographes qui ont l'air bizarres pour... quelqu'un. Le choix des orthographes américaines/britanniques/autres est laissé comme un exercice pour l'auteur de chaque morceau de documentation. Lorsque vous corrigez une documentation, essayez d'imiter la documentation qui vous entoure, plutôt que de modifier la prose existante.

En général, la documentation devrait décrire ce que Perl fait "maintenant" plutôt que ce qu'il faisait auparavant. Il est parfaitement raisonnable d'inclure des notes dans la documentation sur la façon dont le comportement a changé par rapport aux versions précédentes, mais, à de très rares exceptions près, la documentation n'est pas "à double vie" -- elle n'a pas besoin de décrire complètement comment toutes les anciennes versions avaient l'habitude de fonctionner.

NORMES DE CONDUITE

Le forum officiel pour le développement de perl est la liste de diffusion perl5-porters, mentionnée ci-dessus, et son bugtracker sur GitHub. Poster sur la liste et le bugtracker n'est pas un droit : tous les participants à la discussion sont censés adhérer à une norme de conduite.

  • Soyez toujours courtois.

  • Respectez les modérateurs.

La civilité est simple : s'en tenir aux faits en évitant les remarques dévalorisantes, le rabaissement d'autres personnes, le sarcasme ou la présomption de mauvaise foi. Il ne suffit pas d'être factuel. Il faut aussi être civilisé. Répondre en nature à l'incivilité n'est pas acceptable. Si vous relayez sur la liste des commentaires non postés par ailleurs par un tiers, vous assumez la responsabilité du contenu de ces commentaires, et vous devez donc vous assurer qu'ils sont civils.

Si la civilité est requise, la gentillesse est encouragée.ed; si vous avez le moindre doute sur votre civilité, demandez-vous simplement : " Suis-je gentil ? " et aspirez à cela.

Si les modérateurs de la liste vous disent que vous n'êtes pas civil, considérez attentivement comment vos mots sont apparus avant de répondre de quelque manière que ce soit. Étaient-ils aimables ? Vous pouvez protester, mais une protestation répétée face à une décision réaffirmée à plusieurs reprises n'est pas acceptable. Protester de manière répétée à propos des décisions des modérateurs concernant une tierce personne est également inacceptable, tout comme le fait de continuer à initier des contacts hors liste avec les modérateurs à propos de leurs décisions.

Un comportement inacceptable donnera lieu à un avertissement public et clairement identifié. Un deuxième cas de comportement inacceptable de la part de la même personne entraînera la suppression de la liste de diffusion et du traqueur de problèmes GitHub, pour une période d'un mois civil. La justification de cette mesure est de donner l'occasion à la personne de changer sa façon d'agir.

Après la levée de l'interdiction limitée dans le temps, une troisième instance de comportement inacceptable entraînera un nouvel avertissement public. Un quatrième cas ou plus entraînera une interdiction indéfinie. Le raisonnement est que, face à un refus apparent de changer de comportement, nous devons protéger les autres membres de la communauté contre de futures actions inacceptables. Les modérateurs peuvent choisir de lever un bannissement indéfini si la personne en question affirme qu'elle ne transgressera plus.

Les retraits, comme les avertissements, sont publics.

La liste des modérateurs sera de notoriété publique. Actuellement, elle est composée de : Andy Dougherty, Karen Etheridge, Ricardo Signes, Sawyer X, Steffen Müller, Todd Rinaldo, Aaron Crane.

CREDITS

"Contrat social sur les modules contribués" à l'origine par Russ Allbery. <[email protected]> et les perl5-porters.