Sujet : open-source
-
Une journée de documentation planifiée attire plus de nouveaux contributeurs qu'un appel permanent à l'aide pour la documentation
Hypothèse : un projet qui annonce une journée unique, avec une liste sélectionnée de petits tickets de documentation, des mainteneurs disponibles pour une revue le jour même et l'étiquette good-first-issue sur chaque tâche, reçoit davantage de modifications de documentation fusionnées venant de personnes n'ayant jamais contribué que lorsque la même liste reste ouverte toute l'année ; une comparaison est proposée à partir de l'historique d'un projet.
-
Après l'arrivée d'un signalement de vulnérabilité : accuser réception, évaluer, corriger en privé, divulguer
Une fois qu'un signalement atteint le contact sécurité du projet, le travail est une séquence datée : accuser réception rapidement, classer (fonctionne comme prévu, bug, demande de fonctionnalité, vulnérabilité), convenir d'un embargo avec la personne qui signale, développer le correctif en privé, obtenir un identifiant CVE, puis publier une version et un avis nommant les versions concernées et corrigées, et créditant la personne à l'origine du signalement. Le guide des mainteneurs de l'OpenSSF et les recommandations de divulgation de GitHub décrivent ce processus ; cet article le condense pour un projet compté entre un et cinq mainteneurs.
-
Le triage des tickets pour un petit projet : un jeu d'étiquettes fixe et une passe régulière
Le triage consiste à décider, pour chaque nouveau ticket, ce qu'il est, s'il est exploitable et à qui revient le prochain geste. Un vocabulaire d'étiquettes réduit en trois familles (type, statut, domaine) associé à une brève passe à cadence fixe maintient l'honnêteté du gestionnaire de tickets ; les étiquettes par défaut de GitHub (parmi lesquelles bug, enhancement, documentation, duplicate, question, wontfix, good first issue et help wanted) constituent un point de départ exploitable.
-
Reconnaître les contributeurs : un tableau de contributeurs par type de contribution, sans classement
La spécification All Contributors demande une section Contributeurs à un endroit bien visible, sous forme d'un tableau du nom, d'un lien et de la catégorie de contribution, incluant tout type de contribution à tout niveau, l'ordre étant sans importance ; elle recommande de n'exclure personne pour un niveau de contribution perçu comme faible. Le trailer Co-authored-by de Git crédite les coauteurs d'un même commit. Ensemble, ils permettent à un petit projet de créditer la documentation, le triage, la conception et les signalements, pas seulement le code fusionné.
-
Cadence de publication pour un petit projet : trains à intervalle fixe contre publication à la demande
Un numéro de version indique ce qu'une publication promet ; une politique de cadence indique quand les publications ont lieu. Rust publie une version stable toutes les six semaines depuis un train nightly, beta, stable ; Python est passé à une publication annuelle de fonctionnalités avec la PEP 602 ; et Django publie ses versions de fonctionnalités selon un calendrier fixe, avec des correctifs publiés au besoin. Un petit projet peut reprendre cette structure : des publications de fonctionnalités sur un calendrier ou quand quelque chose de notable s'est accumulé, des correctifs dès qu'une réparation est prête.
-
Un fichier CONTRIBUTING qui répond aux cinq premières questions d'un nouveau venu
Avant d'écrire du code, une personne souhaitant contribuer se demande : ce changement est-il souhaité, comment le proposer, que doit contenir une pull request, combien de temps avant une réponse, et comment un changement fusionné atteint-il les utilisateurs. Un fichier CONTRIBUTING qui répond à ces cinq questions dans l'ordre, et qui renvoie ailleurs pour le reste, vise à éviter les pull requests qui seraient rejetées pour une question de périmètre ou de tests manquants.
-
Refuser une demande de fonctionnalité sans perdre le contributeur
Un refus qui s'appuie sur un périmètre écrit, arrive rapidement, propose une alternative et clôt le fil est plus bienveillant que le silence, et il permet de garder le demandeur comme contributeur. Les Open Source Guides notent que le fait d'écrire les choses facilite le refus, et qu'une réponse demande rarement plus d'une ou deux phrases.
-
Déprécier une fonction dans une bibliothèque : avertir, documenter le remplacement, supprimer selon un calendrier
Une dépréciation dans une bibliothèque comporte quatre volets : un remplacement qui existe d'abord, un avertissement à l'exécution complété d'une note de documentation nommant la version et le remplacement, une entrée dans le journal des modifications, et une version de suppression fixée à l'avance par une politique. La PEP 387 exige une période de dépréciation d'au moins deux ans sous la cadence annuelle de Python, et décrit une dépréciation douce, purement documentaire ; Django ne retire les rustines de compatibilité (shims) au plus tôt que deux versions fonctionnelles après l'avertissement.
-
Les dépôts dont l'installation tient en une commande vérifiée reçoivent davantage de contributions de premières fois que les dépôts à installation manuelle
Hypothèse : le README « scripts-to-rule-them-all » de GitHub affirme que réduire la friction d'installation est essentiel pour des contributions plus rapides et plus satisfaisantes ; la proposition reformule cela de façon mesurable, en prédisant que les dépôts dotés d'une commande d'installation unique et auto-vérifiante montrent davantage de pull requests de contributeurs novices, une plus grande proportion réussies dès le premier envoi, et moins de problèmes d'installation que des dépôts comparables à étapes manuelles décrites dans le README.
-
La gouvernance d'un petit projet : des droits de décision écrits avant d'en avoir besoin
Un fichier de gouvernance répond aux questions suivantes : qui peut fusionner, qui tranche un désaccord de périmètre, comment les mainteneurs sont ajoutés et retirés, et comment les règles elles-mêmes changent. La PEP 13 de Python présente un modèle de conseil dont l'autorité est censée être exercée rarement et avec une délibération publique ; le glossaire d'Apache définit le consensus tacite (lazy consensus), selon lequel une proposition passe si personne ne s'y oppose dans un délai fixé. Un projet avec un à trois mainteneurs n'a besoin que d'une page.
-
Comment les mainteneurs de petits projets passent-ils réellement leur temps, et qu'est-ce qui a déplacé la répartition loin de l'écriture de code ?
Question ouverte : les Open Source Guides observent que les mainteneurs de projets largement utilisés finissent par coder moins et répondre davantage aux tickets, et recommandent comme remèdes la documentation, le fait de savoir dire non, le partage de la charge et l'automatisation ; ce qui manque, c'est un temps mesuré par activité pour les petits projets, et des preuves sur lesquels de ces remèdes ont changé la répartition.
-
Passation de maintenance et facteur bus : ce qu'un successeur doit pouvoir faire dès le premier jour
Un projet survit à son mainteneur lorsqu'une seconde personne détient déjà chaque compte et chaque clé, peut effectuer une publication à partir des seules étapes écrites, et sait où les décisions sont consignées. La PEP 541 montre ce qui se passe autrement sur PyPI : un projet n'est considéré comme abandonné que lorsque le propriétaire est injoignable, qu'aucune publication n'est parue depuis douze mois et que sa page d'accueil ne montre aucune activité, et ce n'est qu'alors qu'il peut être confié à un nouveau propriétaire au titre de la règle d'abandon. Le transfert de dépôt de GitHub déplace les issues, les pull requests, les étoiles et les observateurs avec le code.
-
Prendre en charge plusieurs lignes de version : quels correctifs vont où
Une politique de support est un tableau des lignes de version, chacune avec un statut (fonctionnalités, correctifs, sécurité uniquement, fin de vie) et une règle indiquant quelles classes de correctifs sont rétroportées vers quelles lignes. Python maintient une série avec des versions correctives pendant deux ans, puis des versions sécurité uniquement pendant trois ans de plus ; Django rétroporte les correctifs critiques vers la dernière version de fonctionnalités, et les correctifs de sécurité et de perte de données vers les deux dernières plus les lignes à support à long terme ; Rust ne prend en charge que la dernière version stable. Un petit projet a intérêt à publier le tableau et à se limiter par défaut à la promesse la plus étroite qu'il peut tenir.
-
Open source sur IBM i : yum, bash comme shell par défaut et démarrage du démon SSH
La pile open source prise en charge par IBM pour IBM i (Node.js, Python, git, bash, etc.) s'installe sous forme de RPM dans /QOpenSys/pkgs via yum et fournit bash comme shell interactif recommandé. Rien n'est accessible à distance tant que le démon SSH n'a pas été démarré explicitement avec STRTCPSVR *SSHD.
Lisible par machine : JSON