à Marseille avec @erational, @ben et moi même on a peu discuté sur les évolutions possibles de contrib.
Voilà un peu nos idées.
L’idée de fusionner contrib et plugins n’est pas forcément si pertinente car le type de contenu n’est pas le même :
- plugin est un annuaire / normalisé en logique « dépot »
- contrib est une doc facon « longue traine » avec beaucoup de contenu + fonctionnalité de forum permettant la liaison avec les utilisateurices qui n’ouvrent pas de ticket (pas de compte ou de bagage technique)
En revanche voici des améliorations souhaite / possible sur contrib
a. Avoir un dashboard listant les plugins disponibles par SVP sans documentation sur contrib (préfiexe disponible dans la table plugin mais pas dans la table rubriques) … en bonus si dispo on ajoute aussi l’info que le plugin possède déjà un readme.md dans le dépot
b. Améliorier l’intégration des README.md et plus largement des markdown depuis la forge
i. Possibilité de dire « cet article est automatiquement rempli depuis un README.md »
- Le / la responsable du plugin crée la rubrique et l’article qui sera automatiquement rempli
- Dès qu’un tag est posé, l’article basé sur README est actualisé, l’enjeu étant que le contenu se trouve en BDD sur contrib pour faciliter l’emploi du moteur de recherche
- Niveau interface publique, un bel encart indiquant :
- « cet article est composé automatiquement » (formulation à trouver)
- date et tag de référence pour la date "Cette documentation est valable à partir de la version X.Y.Z du plugin, en date du DD/MM/YY)
ii. Pouvoir généralisé à d’autres articles qui pourraient utiliser d’autres markdown livrés dans le plugin qui seraient dans un dossier documentation de la forge
iii. Idem pour détection de la CHANGELOG
Un plugin dont les dev choisiraient de documenter sous forme de markdow (éditable via la forge gitlab pour les gens qui ne connaissent pas git), aurait donc la structure suivante
Bonnes idées d’améliorations oui. Cependant je ne suis pas d’accord pour l’instant sur le fait qu’il serait toujours pertinent de garder deux sites.
L’argument de « comment c’est découpé/architecturé » derrière n’a pas d’importance pour les gens qui cherchent un plugin : ils cherchent un site contenant « tout ce qui n’est pas le noyau, tout ce qui est des fonctionnalités additionnelles » : aucun besoin de les diriger vers deux sites différents, alors que ces deux sites parlent à 99,99% de la même liste de contenus ! (les plugins)
Le site Contrib contient d’ors est déjà en arrière plan technique 100% des mêmes informations que plugins.spip (les dépôts, catégories, plugins, paquets précis de versions précises)
en conséquence de quoi, il s’agit majoritairement d’un problème d’UX : il est parfaitement possible dans Contrib, de présenter des pages/onglets/whatever, qui correspondent à la recherche par dépôts/plugins, tout en ayant pour chaque un lien direct vers les documentations associés. Mais il n’y a pas de raison logique de les forcer à alterner entre deux sites qui parlent vraiment des mêmes choses, et qui contiennent déjà les mêmes infos techniques.
A noter que les catégories sautent, sur les plugins, elles ne sont plus obligatoires (voir à supprimer si j’ai bien suivi ?).
Du coup, je ne sais pas comment ça se passe avec le classement actuel sur plugins.spip et sur contrib.
On n’aurait donc plus que le rubriquage de contrib (?), géré manuellement ?
l’enjeu étant que le contenu se trouve en BDD sur contrib pour faciliter l’emploi du moteur de recherche
Oui, absolument.
Idem pour les autres fichiers (documentation).
Et j’aime bien l’idée d’une norme pour de la doc en markdown
Prévoir de gérer aussi des images (captures écran) insérées dans les .md et présentes dans le dossier documentation ?
C’est déjà ce que je fais dans mes plugins persos, mais je mets ça dans _docs pour que ce soit classé au début et pas au milieu (mais c’est un détail).
Concernant la fusion de contrib et de plugins, c’est le retour de erational et de ben. Perso je suis neutre. A voir si des gens qui pensent que c’est utile et on le temps et la motive pourraient faire une telle maquette de fusion.
Concernant les catégories :
Elle ne sont plus déclarés dans paquet.xml mais se déclarent dans l’espace privé de contrib dans le dashboard des plugins (oui c’est un peu masqué et abscons)
J’ai oublié de préciser dans le CR (car on n’en a pas parlé avec erational, mais j’en avais discuté un jour avec eric et il était d’accord avec l’idée) mais l’un des chantier possible serait de faire en sorte que lorsqu’un rubrique est créée dans contrib associé à un plugin (prefixe) alors il va associer automatiquement le plugin à la catégorie dans laquelle se trouve la rubrique. Ce qui éviterait d’avoir à faire des affectations à la main de catégorie. En soit ce sont a priori 2 deux lignes de pipelines spip à faire.
Et donc oui c’est d’autant plus Contrib qui est là référence des plugins depuis déjà un moment, c’est là qu’ils sont catégorisés, c’est « la source de vérité centrale » en plus du fait que 100% des infos présentées dans plugins.spip sont déjà forcément dans Contrib.
Désolé de ne pas avoir répondu plus tôt à ce fil qui pourtant m’implique beaucoup. Néanmoins, @rastapopoulos a dit l’essentiel.
Oui il faut fusionner Plugins SPIP et Contrib car cela me demande aujourd’hui sans que vous le voyez de synchroniser les sites au niveau des catégories et de maintenir deux squelettes/plugins qu’il serait avantageux de fondre.
La base de référence sur Plugins SPIP et Contrib est mise à jour quotidiennement par CRON mais franchement je ne vois pas l’utilité de doublonner ces informations surtout dans l’optique de séparer SVP à terme.
En outre, Contrib contient aujourd’hui 90% d’articles sur les Plugins.
Je rappelle aussi que ceux qui veulent se documenter ont toujours accès à une doc sur la transformation de Contrib et que nous avions à plusieurs défini dans un doc partagé en md une proposition de pages pour la fusion. J’avais aussi défini des workflows pour ajouter un plugin dans Contrib que je n’ai pas implémenté vu que déjà ce qui existe n’intéresse que peu de personnes. Mais si on s’y remet je suis prêt à y revenir.
Donc oui il faut absolument fusionner ces sites et le plus tôt sera le mieux. Je suis toujours partant pour y travailler en back-office mais je ne pourrais pas faire évoluer Contrib graphiquement pour y intégrer Plugins SPIP.
Les catégories sont actuellement motorisées par le plugin SVP Typologie qui a étendu la notion initiale pour affecter aux plugins les catégories qui avaient fait l’objet d’un long débat il y a quelques années et permettre de définir des tags (utilisés pour les pages de stats de Plugins SPIP).
Pour ce faire, il existe une interface dans Contrib et aussi dans Plugins qui permet de faire les affectations, de les exporter et de les importer (c’est comme ça que je fais la synchro).
En outre, les plugins étant des objets, ils ont une page standard du privé dans laquelle on peut consulter certaines infos et naviguer aussi vers la documentation si elle existe. Je ne sais plus comment sont les autorisations à ces pages, mais il est possible de les adapter si besoin.
C’est ce que j’avais commencé comme intégration dans le plugin qui motorise Contrib car je trouvais que le plugin Show Readme était trop « manuel ». Donc oui, tout à fait d’accord avec cette logique.
J’avais mis à dispo un bout de serveur à cette époque là, pour qu’on travaille sur une copie du site, avec accès ssh pour git.
Je l’ai supprimée très récemment parce que ça occupait un peu d’espace + des sauvegardes, et que ça ne servait plus.
Mais si vous voulez je peux remettre en route très vite, il me suffirait d’un dump de la base je pense, après nettoyage des auteurs (pas besoin de toute cette liste, cf RGPD) en ne gardant que les 2/3 qui bosseraient dessus.
Et peut être de /IMG ? ça risque d’être lourd ça par contre (?)
Au moins les images quoi.
« Il y a 2 squelettes à maintenir » : après une fusion des 2 sites, il y aura quand même des squelettes différents pour les différentes parties du site qui de l’une proposent du rédactionnel, de l’autre présentent des fiches techniques des plugins. N’est-il pas ? Et des objets spécialisés qui serviront aux 2 squelettes.
Une solution n’a pas été évoquée pour l’instant : un seul SPIP et une seule BDD, mais 2 NDD comme maintenant.
2 noms de (sous-)domaines (et notamment plugins. et contrib. comme aujourd’hui) ça introduit toutefois aussi des complications car SPIP-dist n’est pas spontanément équipé pour cela… mais ya des articulations dans les possibles.
Je pense que l’idée est de ne plus en utiliser qu’un à terme (contrib je pense).
Avec une redirection de plugins vers contrib.
Il faudra d’ailleurs veiller à translater les urls, par exemple de Saisies pour formulaires - Plugins SPIP vers l’url de la rubrique qui a le préfixe correspondant.
Par exemple une redirection dynamique, de https://plugins.spip.net/([^.]*).html vers un script sur contrib qui retrouve la rubrique.
