Bonjour, polatouches resplendissants et écureuils débonnaires,
Face à une demande populaire dans le thread Migration de la zone vers un Gitlab, je prends le temps d’écrire un mini résumé (partiel et partial) de quelques jours où certaines personnes se sont retrouvées pour parler de SPIP ; Je ne sais plus combien nous étions, environs 10 ; toustes n’étaient pas là aux mêmes jours. Il y avait b_b, James & moi, et d’autres qui n’auront qu’à s’exprimer s’iels le souhaitent.
James voulait parler de Composer & d’architecture de code, b_b voulait parler de groupes de travail, et moi avancer sur SPIP 5 et ses réflexions.
Être plus serein sur les releases
En préambule, b_b et moi avions été très épuisés de la release de SPIP 4.2
- on s’était sentis un peu seuls
- des éléments ont été ajoutées aux derniers moments qui ont rendu les pre-releases instables
Et ça nous fatigue un rien car il y a de nombreux mois avant la release qui servent à apporter et consolider des améliorations, mais c’est très souvent la dernière semaine avant la date butoir que le monde se réveille insistant qu’il faut en profiter pour intégrer ceci ou cela en débarquant d’un coup, décalant de facto le calendrier prévu le temps de stabiliser.
Du temps pour le fonctionnel
L’autre constat, c’est que compte tenu des faibles forces en présence sur le maintien et actualisation du code SPIP d’une part, et l’envie (marcimat, James au moins) d’aller vers un code plus robuste d’autre part, il nous parait important de se concentrer sur des taches qui sont de l’ordre de l’évolution technique et fonctionnelle de SPIP, et non sur des taches de maintien d’outils spécifiques (de release, de zips, de forge, de tests unitaires, …) et de remplacer une partie des fonctionnalités techniques par des librairies externes éprouvées qui ne sont pas développées et maintenues par l’équipe SPIP, notamment certains modules symfony. Bref, passer le temps dont on dispose à faire évoluer SPIP directement, plutôt que gérer des spécificités, et utiliser des automatismes d’autre part, CI notamment.
SPIP sur Github
Compte tenu du point précédent entre autres, migrer le core SPIP sur Github paraissait une solution satisfaisante, à la fois pour se décharger du maintient d’une forge parfois capricieuse, et pour se faciliter infiniment la tache sur l’intégration avec Composer / Packagist, tout en ayant aucun outil tierce à gérer de notre côté.
Ce sujet fut tendu (parce que Github c’est le mal), mais les participant·es présent·es étaient d’accord, bien que fébrilement. Cela étant, Cédric, qui n’était pas présent, s’est senti dépité et perdre motivation si cette solution était choisie, ce qui a crée aussi d’autres tensions d’ailleurs, sur la difficulté de prendre des décisions et de qui les valide ou pas au final.
SPIP & Composer
L’autre point qui ennuie et dont on n’a aucune solution actuellement c’est de permettre des librairies Composer dans les plugins, via l’interface d’administration des plugins de SPIP.
C’est pourquoi (James & moi) on se garde bien d’aborder ce sujet délicat, pour se concentrer d’abord si possible sur cette utilisation uniquement pour le Core et les plugins-dist fournis, dans la mesure de nos forces.
Sans être sur Github ou Gitlab.com, déjà cette gestion complique et oblige à utiliser un outil tierce, Satis (il existe aussi d’autres outils payants). C’est ce qui est mis en place actuellement, avec quelques doutes sur la montée en charge quand il y aura beaucoup de dépôts et son maintien dans le temps.
Recenser les forces vives !
Avec le temps, il devient nécessaire de faire un tour des forces restantes dans SPIP, le core notamment, pour savoir qui a encore envie d’y participer régulièrement et activement.
Il y a 2 gros points : destructurer la team et établir des équipes spécialisées.
la team
Elle est responsable actuellement de
- traiter et corriger les failles de sécurité
- réviser, merger les PRs et les reporter dans les branches concernées
- garantir le respect du cycle de vie des branches
- releaser
- la maintenance des serveurs qui hébergent des trucs de la communauté
- … et dispose de droits de commit sur l’organisation spip donc
il y a 30 personnes dans le core, mais combien sont encore actives / intéressées par l’objet principal du groupe : la prise en charge les signalements de failles de sécu ? 7 max ? Le fait que ces personnes devenues inactives aient toujours des accès importants est un problème de sécurité en soit.
L’idée serait de redemander à chacune de ces personnes ce à quoi elle a envie de participer ou pas et de dispatcher les personnes volontaires dans des équipes aux rôles plus spécifiques…
équipes spécialisées
Ainsi il pourrait être proposé une structure différente en s’appuyant sur des équipes dont les personnes ont envie de s’investir sur des sujets plus précis.
Par exemple il pourrait être envisagé des équipes identifiées de :
- sécurité: pour l’analyse et traitement des failles,
- maintenance: pour réviser, merger les PRs et les reporter dans les branches concernées
- architecture & DX : définir la vision souhaitée à long terme du code,
- fonctionnel & UX : définir les fonctionnalités maintenues et souhaitées,
- documentation,
- traduction,
- modération (sur Discuter)
- animation (organiser des rencontres, comptes rendus, etc…)
- …
Outre les membres actuels du core, il pourra être possible d’intrégrer donc d’autres personnes motivées par le projet dans ces équipes, en accord avec les valeurs initiales du projet SPIP évidemment. La question de comment on valide sera toujours délicate à trancher.
L’idée aussi est que ces attributions ne sont pas éternelles, et que les membres puissent partir ou revenir au gré des motivations et du temps libre.
Sur ces tâches, il sera important d’exposer le manque de forces vives là où c’est le cas, les membres du core doivent savoir « laisser de la place » afin de permettre aux personnes volontaires de s’impliquer.
Voilà en gros ce qui s’était partiellement discuté ; d’autres personnes complèteront peut être…
Toujours est-il qu’il ne s’est rien passé depuis, sinon beaucoup de démotivation un peu partout.
Matthieu & b_b
