Bonjour
sans parler du contenu, un des trucs de l’IA si iel n’est pas guidé est de reprendre la façon dont la majorité des textes est écrite, avec ses travers.
Pour s’adresser à une communauté ouverte (qui a très peu de participantes comme beaucoup de projets libres) SPIP essaye d’éviter les terminaisons masculines. Ce que ne fait pas Chattruc.
Ainsi, on préfèrera écrire « les personnes qui font du développement » ou « les personnes qui utilisent » plutot que développeurs ou utilisateurs. Quand on ne peut pas écrire de façon épicène, on met alors un point médian.
Petit rappel qui fait que du bien :*
3 « J'aime »
Je conçois. Je ne suis pas sensible à cette thématique et cela ne me dérange pas que le texte soit modifié dans ce sens avec des termes neutres comme « personnes ». Perso, je n’aime pas trop les iel, iul & Co. Et les points médians - même s’il existe 1 ou 2 projets OpenSource avec lesquels ça fonctionne - sont souvent mal interprétés par les lecteurs d’écrans ce qui ne favorise pas l’accessibilité (a11y). Sans parler des dyslexiques. J’ai modifié le texte pour qu’il soit plus inclusif 
2 « J'aime »
Un petit mot sur le PDF / epub pour les rédactrices & rédacteurs rédigé et actualisé par @Ysabeau pour SPIP 4 SPIP 4 : vu du côté de la rédaction - Modèles et guides qui très propre ?
[Un guide pour] des personnes qui sont amenées à rédiger ou administrer un site tournant avec ce logiciel de gestion de contenu mais n’ayant pas à intervenir sur l’aspect technique. À récupérer en version PDF ou EPUB.
Note
- Les images sont un peu trop compressées dans le PDF je trouve, mais bon ;
- les captures montrent certains plugins activés en plus, sur la barre typo notamment
2 « J'aime »
Salut @paidge,
Merci pour ta contribution 
Ce n’est pas une thématique mais un sujet de fond qui a longuement été débattu ici (ce commentaire n’a pas pour but de relancer le débat) et qui est inscrit dans la charte de la communauté SPIP : « respect de l’identité de chaque personne »
C’est donc une demande de la communauté dans son ensemble que les textes soient le plus inclusifs possible, donc soyons tous et toutes vigilant·es lors de la rédaction (et je m’inclue dedans 
).
1 « J'aime »
Je t’ai demandé de modifier ton texte pour qu’il soit inclusif, je ne m’attendais pas à ce que cela te serve à étaler ton point de vue masculiniste. C’est dommage et pour toi qui étale ta suffisance sans vergogne et pour moi qui prend encore et toujours sur moi de rappeler que l’écriture chez SPIP est inclusive.
Décrotter vous le cerveau les mecs là, à part jeanmarie personne ne dit rien comme d’hab ??
11 messages ont été scindés en un nouveau sujet : Débat sur le respect de l’identité de chaque personne
Un message a été fusionné à un sujet existant : Débat sur le respect de l’identité de chaque personne
2 messages ont été fusionnés à un sujet existant : Rappel sur le respect de l’identité de chaque personne
Alors quoi de nouveau dans la galaxie SPIP ?
Il s’est passé des trucs à relayer la semaine dernière ?
le travail de james sur la décomposition du code de spip en petit morceaux modulaire ?
(Mais je pense que globalement on pourrait relayer toutes les publications récentes de contrib, voir même imaginer un modèle pour les récuperer automatiquement…)
1 « J'aime »
Il y a à ce jour 314 plugins compatibles SPIP4.2. Il y en avait un peu moins de 250 début mai. Dans la plupart des cas, c’était « juste » un problème de borne supérieure de compatibilité…
2 « J'aime »
@JamesRezo Je pourrais recopier ton texte sur la décomposition du code de spip en petit morceaux modulaire, mais je n’en connais pas les tenant et les aboutissants alors pourrait on plutôt le décrire de manière simple ?
Pourrais tu indiquer, par exemple en 1 phrase pour chaque point :
- dans quel projet à long terme cela s’inscrit il ?
- qu’as tu fait (grosso modo) ?
- en quoi ce travail sert il ce projet, à court ou moyen terme ?
- quel est le principal résultat intéressant ?
- quelles sont les (ré)orientations induites et les suites à court terme ?
Une news plus côté développements : phpstan, phpcbf, rektor et autres outils de qualité de code, en 2 parties :
- objectifs : en parler d’un point de vue conséquence pour la communauté et l’avenir de SPIP : une montée en qualité et sécurité
- méthodes et outils : une description de chaque outil et comment les utiliser
Bah tu ne m’épargnes pas ! 
1 phrase par réponse, rha la la, on va me reprocher d’être lapidaire (ou hermétique) ^^
Nan, chouette exercice. J’essaie.
Le projet à long terme est de sortir SPIP de son isolement technologique vis-à-vis de l’écosystème PHP.
Ce qui est fait à ce jour, c’est l’assemblage de la distribution classique de SPIP avec composer pour SPIP5.0, qui devrait sortir en début d’année prochaine. La suite, pour les 6 mois (le court terme) qui nous restent jusque là, c’est de tenter de remplacer la plus grosse part possible du PHP historique du dossier ecrire/ par des composants (pas des plugins) techniques spécialisés, basés eux-même, dans la mesure du possible, sur des lib externes plus sûres, maintenues par d’autres pour allégeer notre propre charge mentale. En ce moment, j’analyse le code existant et je classe les fonctions, les fichiers, les globales, les constantes. On aura peut-être besoin d’étaler ça sur un peu plus temps plus long. On verra …
À moyen terme, (disons pour les 3 années suivantes ? pour les SPIP 5.x grosso modo ?) ça nous permettra, d’assurer plus facilement la compatibilité des plugins communautaires, et donc les diverses montées de version, mais ausi, je l’espère de ne plus avoir besoin d’un dossier physique ecrire/, de faire des distributions « moins classiques » plus facilement, de proposer d’autres manières de sécuriser des applications SPIP sur le web, de ne plus copier/coller du code de lib externes dans des plugins, voire des dossiers vendor/ entier …
Le résulat principal intéressant, pour le moment, bah ça dépend de ce à quoi on s’intéresse, forcément… mais je pense que l’assemblage de spip avec composer, ça nous facilite pas mal la production des zip de spip et donc des releases mais aussi pour les devs en local (mais c’est plus aux autres de le dire…). Si on tient nos objectifs, ça devrait aussi être plus facile de maintenir des plugins…
Les orientations induites, sans être 100% sûr de répondre à ta question, c’est qu’on bénéficie des standards d’autoloading partagés avec l’écosystème PHP: on peut donc faire du code objet, ce qui nous facilite notament la production de tests unitaires automatisables (parce que c’est plus facile de tester des classes que des fonctions mélangées à des globales, par exemple)
4 « J'aime »
Merci James. Il y a plus d’une phrase par point, alors ça reste pas évident à comprendre… mais ça ira bien pour les spipeurs concernés.
À part ça, suite à suggestion de @b_b, je préparerai un bestof des trucs les plus inintéressants de Truc super pas intéressant
Et je relève aussi l’échange à propos de la personnalisation des notifications de formidable :
==== DÉBUT
Q: Je voudrais insérer des liens actifs dans le courriel envoyé par Formidable, via un champ pré-rempli au chargement.
A: Il faut créer ton propre squelette notifications/formulaire_XX_email.html pour le formulaire XX en question (XX étant l’identifiant, pas le numéro). Et là tu peux récupérer ton champ caché dans #ENV{valeurs/tonchamp} et construire le squelette du mail avec.
=== FIN
je ne suis pas sur que cela vaille la peine d’en faire une news.
En effet je savais pas mais c’est dans la doc de Formidable.
Alors ça pourrait (quand même) aller dans la super rubrique des « Trucs pas intéressants »
Idem et pour la même raison cf paquet.xml -> <procure> ?
==== DEBUT
Question : Dans quel cas faut il déclarer une balise <procure> dans le fichier paquet.xml ?
Réponse :
- Ça peut servir quand un plugin fournit une librairie dans le dossier « lib »
- Ça peut aussi servir à un plugin d’indiquer qui supplante un autre (car il a intégré ses fonctionnalités), exemple avec SPIP qui indique qu’il procure les fonctionnalités de l’ancien plugin itérateurs spip/paquet.xml at master - spip - SPIP on GIT
==== FIN
==== DEBUT #SPIP5
Depuis le commit 7e0ef909, les CSS de la dist utilisent des variables CSS. Elles sont séparées en 2 :
- Des variables « publiques » qui pourront être communiquées, elles permettent de modifier simplement les principaux éléments qui régissent l’apparence du thème : couleur d’accent, etc.
- Des variables « privées » à usage interne, qu’il n’est pas recommandé de surcharger dans ses styles persos.
Exemple :
.success {
background: var(--dist-color-success-bg);
color: var(--dist-color-success-text);
border-color: var(--dist-color-success-border);
}
==== FIN
Sur discuter.spip, ya eu / ya encore / des échanges sur plusieurs sujets qui pourraient trouver un écho dans la news en rubrique #Politique (ou « Météo politique », ou « le web c’est politique »…).
De mémoire :
- L’inclusivité dans la communauté SPIP
- Les plugins payant / le modèle économique du dev SPIP
Je pourrai faire une synthèse sur ces sujets, mais c’est délicat. Faudra t il soumettre la synthèse à validation collective ? Comment et par qui ?
Si qqn veut s’occuper d’un de ces sujets c’est très bienvenu aussi.