Re: Composer et SPIP sont dans un bateau

Hello,



Le jeu. 21 mars 2019 à 17:12, James <[email protected]> a écrit :

> Salut les amis,
>
> Pour rappel, alors qu'on ne parle de Composer que depuis un an sur cette
> liste, et alors que cet outil n'a toujours pas été introduit en tant
> qu'outil de développement pour celleux qui produisent du code dans le CMS
> SPIP, ce projet PERD des utilisateurs.
> Ceci depuis au moins 6 ans.
> Pas besoin de composer pour ça.
>

Oui mais là on est dans le raccourci.
Il faut distinguer les profils d'utilisateurs : les développeurs, les
intégrateurs (qui sont quand même la cible principale actuellement de
SPIP), les rédacteurs d'articles qui ne font que naviguer dans l'espace
privé en ne sachant rien de SPIP ou presque et les créatrices de site pour
le plaisir ou pour une association, qui ne connaissent rien à
l'informatique mais qui veulent écrire des articles avec des potes et les
afficher d'un façon "moderne" en choisissant le layout et les couleurs
simplement. Ces derniers je les connaissaient très bien car c'étaient les
utilisateurs privilégiés de Sarka-SPIP...
Il y a surement d'autres profils mais en se limitant à ceux-là savons nous
qui on perd ?
Si j'extrapole ce que tu n'as pas dit ;-) je dirais des devs puisque
Composer ne s'adresse qu'à eux.
Moi je ne suis pas sur.

Et surtout je ne suis pas sur que la réponse Composer soit adaptée aux
autres profils que les devs.
Alors oui on aura surement marqué un point important dans l'intégration
vers un écosystème PHP moderne et plus attractif actuellement mais ça ne
changera rien pour les rédacteurs et autres créateurs amateurs.
Si je fais le parallèle avec mon expérience professionnelle, les systèmes
métro, ont se fait hyper chier à rénover les systèmes d'automatismes et de
sécurité avec les problématiques que tu peux imaginer. Et bien que vois les
gens ? La couleur et le design du nouveau train ou le nouveau carrelage de
la station.
Je pense que l'ergonomie du privé et l'accès à des squelettes facilement
paramétrables (noisettes, layout, thèmes roller...) sont des chantiers bien
plus attractifs pour certains profils d'utilisateurs. Et nous avons tous
les moyens pour ça avec ZCore, N-Core, le noiZetier, les squelettes Z....
C'est tellement plus visible de l'extérieur.

Mais ça ne veut pas dire que le pas Composer ne doit pas être fait.
Au contraire tout pas DOIT être fait car à minima ça anime la communauté et
lui évite de rester dans une léthargie néfaste.
Donc j'y suis favorable mais pas pour les raisons que tu invoques mais il
ne faut pas s'arrêter là dans les grands chantiers.


>
> Pour certains d'entre nous, c'est un sujet d'inquiétude, pour d'autres,
> c'est un faux problème. Pour d'autres encore, ce n'est même pas un fait
> entendable ...
>

Oui c'est inquiétant et surtout pas mérité vu la qualité du logiciel.


>
> Si ça vous inquiète vraiment, parlons-en, cherchons des solutions.
> Cherchons alors à comprendre pourquoi on perd aujourd'hui des utilisateurs
> alors que rien n'a vraiment bougé sur le plan technique depuis ... allez,
> disons une dizaine d'années... (et je ne fais aucun sous-entendu ni de
> reproche)
>

Voir plus haut.


>
> Ensuite, pour rappel toujours, à propos de la disparation de l'interface
> graphique d'ajout de plugins : Il n'en a jamais été question.
> C'est tout. C'est simple. Personne n'a annoncé que SVP allait disparaître.
> Personne n'a dit qu'on allait contraindre des utilisateurs ayant peu de
> compétences informatiques à taper des lignes de commandes. Il est aussi
> tout à fait abusif de laisser entendre que des membres de la team
> envisagent d'en faire le système par défaut de tous les utilisateurs de
> SPIP.
>
> Arrêtons les fantasmes un instant, s'il vous plaît.
>

Je ne crois pas que ce soit un fantasme mais plus une incompréhension.
Et aussi la connaissance de l'histoire plus si minuscule que ça de SPIP qui
montre que les changements sont... lents.


>
> On évoque en toute transparence, depuis un an maintenant, que le chantier
> sera difficile et que ça demande donc de se faire une sorte de roadmap avec
> des jalons.
>
> On se fixe comme *première étape* de transformer le bloc de base (le core,
> ses plugins-dist, son squelettes-dist et l'écran de sécurité) en une liste
> exhaustive de composants assemblables par composer pour produire EXACTEMENT
> un SPIP classique. La maquette SpipRemix présentée l'an dernier sur cette
> liste rempli cet objectif. Pour cette étape, on ne parle pas de la zone, On
> ne remet pas en question la manière de faire des plugins et des les
> distribuer. Cela implique le maintien de SVP dans une distribution
> classique de SPIP, le maintien de spip_loader, celui de files.spip.net,
> et de plugins.spip.net, le maintien (pour les plugins de la zone,
> toujours) de l'empaqueteur et des fichiers archivelist.txt, le maintien de
> salvatore, le maintien de trad.spip.net, le maintien de subversion comme
> serveur de gestion de version pour la zone... Tout reste. Rien ne bouge.
> Rassurés ? :-)
>

Oui sauf pour Plugins SPIP.
Les plugins de la dist n'y seront plus sauf à faire un truc spécial pour
les réintégrer.
Tu me diras vu qu'ils ont presque pas de documentation...
Si on est d'accord d'accepter ça un temps pourquoi pas.


>
> - Un mini-spip, avec le moins de plugins-dist possible, voire un SPIP nu,
> sans plugin du tout, pour servir de base à d'autres distributions, à
> d'autres développements. Mais c'est une autre histoire.
>
>
Ca sert à quoi surtout si on a deux sources de plugins ?
Là je trouve que c'est une source de confusion.


> La préoccupation principale semble être SVP. Soit. On vous accueille à
> bras ouverts pour avancer sur le sujet.
> Mais le vrai problème urgent qui vient, c'est qu'il y aura nécessité à
> changer le fonctionnement de trad.spip.net pour fonctionner avec git et
> composer. Là, on aura besoin d'aide, de la patience et de la bienveillance
> de la part de toute la communauté. Répondrez-vous présent ? Mettrez-vous la
> main à la pâte ?
>

Ok.
Faut juste nous y embarquer avec douceur car on est pas tous rompus au
sujet.
Et ce qui serait bien c'est aussi d'embarquer un groupe vers les autres
sujets que j'ai mentionné.
Sinon, on ne fera de SPIP qu'une plateforme technique, c'est toujours ma
crainte depuis le début de cette proposition.

++
Eric