Re: Changer la gestion des catégories de pl ugin

Le 18/05/2019 à 14:59, Eric Lupinacci a écrit :
> Hello,
> 
> Sur les conseils avisés de Maieul, je relance un nouveau fil de 
> discussion dédié à ce sujet précis car l'autre fil avait plus pour objet 
> le découpage fonctionnel de SVP.
> Ce fil y participe mais concerne uniquement la gestion des catégories.
> 
> 1) CONSTATS
> 
> 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.
> 
> 2) PROPOSITION
> 
> 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" (un plugin à part).
> 
> 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).
> - sur le même principe il devient possible de mettre en place une 
> "folksonomie" à base de tags pour compléter le rangement en catégories.
> 
> 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.
> Je suis en train de maquetter un plugin SVP Typologie pour démontrer 
> l'intérêt de cette approche.
> 
> ++
> Eric
> 
Comme dit, je partage l'analyse (je relis aussi les 1200 plugins en ce 
moment) et la conclusion.