Re: Catégorie de plugins, SVP, SPIP et Composer

Le 17/05/2019 à 19:49, Eric Lupinacci a écrit :
> Yo yo,
> 
> 
> Le ven. 17 mai 2019 à 17:27, nicod_ <[email protected] 
> <mailto:[email protected]>> a écrit :
> 
>     Le 17/05/2019 à 13:56, Eric Lupinacci a écrit :
>      > Oui on peut le voir comme ça.
>      > Je m'interroge juste sur l'intérêt du truc.
> 
>     De ne pas se fermer une possibilité d'extension ?
> 
> 
> Oui et non, je vais expliquer le truc globalement à la fin du mail
> 
> .
> 
>      > En fait, il n'y a aujourd'hui (faudra que je vérifie quand même)
>     pour
>      > moi qu'un fil à la patte entre SPIP et les catégories.
>      > C'est la validation du paquet.xml.
>      > La DTD impose une liste :
>      > <!ENTITY % CATEGORY
>      >
>     "auteur|communication|date|divers|edition|maintenance|multimedia|navigation|outil|performance|squelette|statistique|theme)"
> 
>      >  >
>      > Si on fait sauter cette contrainte, en conservant le caractère
>      > obligatoire de l'attribut, en remplaçant cette liste par une simple
>      > chaine je pense qu'on simplifie le problème.
> 
>     Ça serait peut être bien pour l'ouverture mais c'est à double tranchant.
>     Si chacun peut mettre sa propre catégorie, la porte ouverte au grand
>     bazar qui deviendrait ingérable ?
> 
> 
> Ne pas le valider dans la paquet.xml ne veut pas dire qu'on ne fait 
> jamais de contrôle.
> Oui on le fait mais pas dans une DTD surtout quand on va passer de 15 à 
> 60 catégories.
> 
>     Mais si la catégorie n'est plus dans le paquet, concrètement comment on
>     la déclarerait quand on crée un nouveau plugin, qu'il soit sur la zone
>     ou sur une autre forge ?
>     Dans un autre référentiel sur la zone ?
>     Source d'oubli potentiel non ?
> 
> 
> Oui on le ferait ailleurs. Avant d'expliquer comment, je voudrais quand 
> même tirer quelques conclusions sur les 10 ans des catégories actuelles.
> 
> Le premier constat qu'on a fait c'est que les 14 catégories existantes 
> étaient devenues trop restrictives et confuses en passant de 300 plugins 
> à 1200. Donc l'idée est de revoir ce classement pour affiner le 
> rangement et le faire mieux correspondre au référentiel de plugins. D'où 
> une inflation, environ 60 catégories à stabiliser.
> Et bien on pourra y passer des heures (je peux le dire en connaissance 
> de cause) on aura du mal à stabiliser cette liste le jour de la "grande 
> migration". On passera donc par une phase surement longue de 
> stabilisation pendant laquelle il faudra faire des changements et ce 
> serait une erreur de l'éviter.
> Donc la *capacité à faire évoluer cette liste est un must* à mon avis.
> 
> A quoi sert cette liste aujourd'hui ?
> Premièrement à regrouper des plugins plus ou moins connexes pour 
> faciliter la recherche des utilisateurs.
> Cette recherche se fait dans Plugins SPIP et dans une moindre mesure via 
> le formulaire de l'admin plugins dans le privé.
> Je suis persuadé que l'utilisation du critère catégorie dans ce 
> formulaire est très limitée.
> Donc en conclusion, c'est principalement *le référentiel des plugins qui 
> a besoin de ces catégories,* ce qui est sur c'est que *SPIP et les 
> plugins fonctionnent très bien sans*.
> 
> Etat de la liste aujourd'hui ?
> En révisant toutes les affectations des 1200 plugins je me suis aperçu 
> qu'environ 50% étaient "mal positionnés" dans le paquet.xml (en tout cas 
> au vu de la compréhension actuelle des catégories) et surtout qu'une 
> grande proportion des plugins documentés sur Contrib étaient affectés 
> différemment dans le paquet et dans Contrib alors qu'il était très 
> facile d'être cohérent. Par contre, en 10 ans j'ai très peu corrigé des 
> catégories manquantes.
> En conclusion, il est *très difficile d'avoir une vision globale d'une 
> catégorie* (Plugins SPIP n'est pas pratique pour ça et une requête  SQL 
> n'est pas à la portée de tout le monde). En outre, *corriger une 
> "erreur" n'est pas immédiat *car il faut le faire via un commit sur la 
> zone, et ce pour toutes les branches zippées voire dans le paquet.xml et 
> le plugin.xml : cela peut rebuter et donc réfréner les volontés.
> 
> Donc toutes ces années d'expérience m'amène à penser que ce système ne 
> favorise pas l'amélioration du classement au fil des années mais 
> exactement le contraire et on se rend compte que son manque de pédagogie 
> fait que les gens s'en foutent ou n'acquièrent jamais un ressenti 
> correct des catégories.
> C'est pourquoi je proposerais finalement (j'ai pas été tout de suite 
> convaincu) de sortir la gestion des catégories de SPIP, donc des XML, 
> pour l'inclure comme une fonctionnalité du site "Référentiel des plugins".
> 
> Les avantages :
> - *Plus de migration ou d'évolution compliquée*. On peut choisir de 
> conserver l'attribut pour éviter 3000 commits en une journée ;-), de le 
> virer de tous les XML (ça serait plus propre). Ce qui est sur c'est que 
> toute évolution de catégories ou d'affectations futures sera totalement 
> indolore pour les plugins, et compte tenu de ma première remarque je 
> pense que c'est essentiel.
> - La catégorisation devient un *sujet uniquement référentiel* ce qui 
> permet d'extraire de SVP toute cette gestion.
> - On peut proposer un *assistant pour choisir sa catégorie* sur le 
> référentiel des plugins en visualisant simplement les autres plugins qui 
> en font partie. Des explications peuvent être données sur les 
> catégories... On peut en faire un élément de pédagogie.
> - si la catégorie est oubliée, le référentiel l'identifie de suite et la 
> *correction est bien plus aisée *que de d'aller commiter sur 1 ou n XML. 
> De même si on se rend compte qu'il faut changer le classement. Tout 
> pourrait se faire sur le site Référentiel des plugins (surement la 
> fusion de Contrib et Plugins SPIP).
> 
> Les inconvénients :
> - Je n'en voit pas. Mais c'est vrai que si on veut remplir le champ 
> catégorie dans la base des plugins de chaque site installé il faut 
> mettre en place un mécanisme type API REST pour récupérer la liste des 
> affectations (préfixe-catégorie)
> Rasta m'a fait remarquer que c'était bien lourd.
> Soit mais c'est oublier que SVP fonctionne déjà comme ça et ce toutes 
> les 6 heures ! Je vois pas en quoi récupérer un json de plus de temps en 
> temps serait si compliqué. Un système de cache pourrait aussi être mis 
> en place.
> Après, si on vire le critère catégorie dans le formulaire admin plugins 
> je pense qu'on peut même s'abstenir de remplir le champ catégorie pour 
> les sites fonctionnant en mode runtime SVP cad tous les sites sauf 
> Plugins SPIP !
> 
> J'ai vraiment l'impression qu'on résout tous nos problèmes ainsi, qu'on 
> s'allège la gestion en se donnant plus de moyens d'avoir une 
> catégorisation fiable et compréhensible et qu'on répond à toutes les 
> interrogations de ce fil.
> 
> ++
> Eric
> 
> 
je partage l'analyse (pour relire aussi la catégorisation) et la 
conclusion. Reste que ceci est perdu au fond d'un fil de discussion, je 
me demande si tu devrais pas reprendre ton mail et le mettre au début, 
sur une nouvelle discussion