[spip-dev] Changer la gestion des catégories de plugin

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.

  1. 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.

Ça me parait pas mal du tout.

Qui aurait accès à la catégorisation d'un plugin sur l'interface ?
Tout le monde ? des admins désignés ?

Yo,

dans la mesure où c'est un travail editorial sur un referentiel de plugin
1. Seul les admin pourraient créer des nouveelles catégories (on devrait par contre avoir un formulaire permettant de suggérer dans créer ...)
2. Les rédacteurs/trices d'article choisissent (en fait c'est juste techniquement un rubriquage)
3. L'administrateur/trice valide lorsqu'il publie l'article

Comme dit, je partage l'analyse (je relis aussi les 1200 plugins en ce moment) et la conclusion.

Ça c'est quand un article de doc est déposé, mais ce n'est pas toujours le cas.
En général, la doc arrive après la publication du code sur la zone.
Et certains n'ont pas de doc du tout.

Ça parait cohérent, et Maieul a la même idée.

Ça se passerait dans une interface spécifique ? Sur une page de contrib ?

oui, mais justement on gèrerait plus la catégorisation par code. Par contre, ce qui comptera c'est l'ajout au référentil de plugin, à savoir contrib. Actuellement le referentiel c'est plugins.spip.net, ce qui fait qu'on a parfois des plugins referencés (c'est à dire zippés) mais non documentés. Je pense pas du tout que ce soit une bonne idée. Un plugin zippé devrait avoir une doc, ou une ébauche de doc, dans la foulée. A la rigueur, on peut imaginer un process qui fasse que si on crée un zip, alors ca crèe automatiquement un article pour la doc, reprenant le contenu minimal, si la doc n'existe pas deja. A voir, a reflechor encore.

Pas évident : un article vide sur contrib n'apporterait rien en terme éditorial.
Et puis comment relier automatiquement l'auteur du plugin à l'auteur de l'article ? C'est impossible.
Il faudrait que l'auteur demande à avoir la main sur "son" article de doc quand il veut l'écrire ?

En même temps, ça permettrait de référencer automatiquement les plugins zippés sur le site contrib éditorial, et pas que dans la liste "brute" des zips, et donc d'améliorer leur visibilité.

pour le coup plugins.spip.net fait cela. Mais du coup on a quand même le problème d'une doc vide. Mais c'est deja le cas sur plugins.spip.net. Par contre l'avantage sur contrib c'est qu'on pourrait pousser des gens à documenter. On pourrait avoir une catégore d'article "documentation en attente de complétion". Ce serait pas publié, ca resterait dans l'espace privé, mais ce serait à part des article "proposé à l'évaluation".

Reste ta question des auteurs. On pourrait envisager que les autrices de contrib ait un champ extra indiquant les pseudo sur lesquels on peut les trouver dans paquet.xml/plugin.xml (perso je suis parfois avec mon nom, parfois juste mon prénom).

Pas évident : un article vide sur contrib n'apporterait rien en terme éditorial.

En même temps, ça permettrait de référencer automatiquement les plugins zippés sur le site contrib éditorial, et pas que dans la liste "brute" des zips, et donc d'améliorer leur visibilité.

pour le coup plugins.spip.net fait cela. Mais du coup on a quand même le problème d'une doc vide. Mais c'est deja le cas sur plugins.spip.net. Par contre l'avantage sur contrib c'est qu'on pourrait pousser des gens à documenter. On pourrait avoir une catégore d'article "documentation en attente de complétion". Ce serait pas publié, ca resterait dans l'espace privé, mais ce serait à part des article "proposé à l'évaluation".

oups, un statut, pas une catégorie d'article

Hello,

pour le coup plugins.spip.net fait cela. Mais du coup on a quand même le
problème d’une doc vide. Mais c’est deja le cas sur plugins.spip.net.
Par contre l’avantage sur contrib c’est qu’on pourrait pousser des gens
à documenter. On pourrait avoir une catégore d’article “documentation en
attente de complétion”. Ce serait pas publié, ca resterait dans l’espace
privé, mais ce serait à part des article “proposé à l’évaluation”.

Reste ta question des auteurs. On pourrait envisager que les autrices de
contrib ait un champ extra indiquant les pseudo sur lesquels on peut les
trouver dans paquet.xml/plugin.xml (perso je suis parfois avec mon nom,
parfois juste mon prénom).

Bon on dérive un peu là les amis ;-).
Mais ça vaut le coup d’y réfléchir.

Dans la doc de la refonte de contrib j’ai identifier des workflows dont un pour documenter un plugin.
Ici on veut catégoriser un plugin qui est “normalement” une opération que l’on fera souvent avant la documentation car les gens ont pris l’habitude de le mettre dans le paquet.xml.
Aussi je me dis que lors de ce workflow, une fois la demande de catégorisation acceptée on pourrait proposer de créer la rubrique et l’article de doc principal. Si le gars dit non il pourra le faire avec le workflow “documenter un plugin” après coup.
Par contre, je ne pense pas qu’il faille lier plus la catégorisation et la documentation.

Mais ça serait mieux de consigner ça sur le framavox, je mettrais la doc à jour en conséquence.

Hello,

> pour le coup plugins.spip.net fait cela. Mais du coup on a quand
> même le
> problème d'une doc vide. Mais c'est deja le cas sur
> plugins.spip.net.
> Par contre l'avantage sur contrib c'est qu'on pourrait pousser des
> gens
> à documenter. On pourrait avoir une catégore d'article
> "documentation en
> attente de complétion". Ce serait pas publié, ca resterait dans
> l'espace
> privé, mais ce serait à part des article "proposé à l'évaluation".
>
> Reste ta question des auteurs. On pourrait envisager que les
> autrices de
> contrib ait un champ extra indiquant les pseudo sur lesquels on peut
> les
> trouver dans paquet.xml/plugin.xml (perso je suis parfois avec mon
> nom,
> parfois juste mon prénom).
>

Bon on dérive un peu là les amis ;-).
Mais ça vaut le coup d'y réfléchir.

Dans la doc de la refonte de contrib j'ai identifier des workflows
dont un pour documenter un plugin.
Ici on veut catégoriser un plugin qui est "normalement" une opération
que l'on fera souvent avant la documentation car les gens ont pris
l'habitude de le mettre dans le paquet.xml.

certes, mais si on fait sorti de paquet.xml, qu'on dit que c'est que le
réferentil qui vaut pour la catégorisation, alors c'est en même temps
que la doc non?

Je dirais plutôt du “Référentiel de plugin” que de la doc.
C’est un peu jouer sur les mots mais ce que je veux dire c’est qu’on pas besoin de trop se lier dans ce cas avec la documentation sauf à proposer une suite.

Enfin à réfléchir.

oui c'est ma proposition, de faire une suite. En gros le workflow pour
moi serait
1. On déclare un plugins au référentiel
  -> ca demande la catégorisation
  -> ca enclenche le zippage (pour ca faut fournir une source de
versionnement)
  -> ca crée automatiquement une rubrique et un article, et cela
propose le choix entre :
    -> je rédige moi même la documentation
    -> je demande à d'autres de le faire, et dans ce cas on un
statut "appel à documentation" et cela apparait dans l'espace privé de
contrib
2. Sur l'espace privé du réferentiel, des gens qui ne sont pas
nécessairement les auteurs du plugins peuvent compléter la documentation
pour les articles "appel à documentation".
3. In fine, dans tous les cas ca repasse par "proposer à l'évaluation",
et par une validation editoriale.

Yo,

Oui je vois.
Là où je diverge un peu c'est que je ne créerait pas une documentation
automatiquement mais je poserais une question : "prévoyez-vous de
rédiger une documentation sur Contrib ?".

mais du coup on pourrait avoir des choses référencés sans documentation?
tu verrais cela comment dans l'interface publique (si on part de l'idée
de fusion contrib/plugins)

Yep,

Ça parait intéressant ce que vous proposez.

Quid de l'existant ? des plugins actuels sans doc sur contrib ?

Et du rangement qu'il va falloir faire sur contrib pour coller aux nouvelles catégories ? (bon, ça, ce sera forcément à la main je pense)