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

Le 18/05/2019 à 16:47, Maïeul Rouquette a écrit :
(...)
> 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.

Hop,

Par rapport aux référentiel
---------------------------

Je m’incruste dans la conversation, et en relation avec Composer, et 
aussi suite à causerie avec James en aparté hier soir.

On se place dans un moment charnière où il y aurait des plugins SPIP 
«composerisés», mais pas tous. L’idée (de ce que j’ai compris) qu’il 
avait en tête en refaisant Smart Paquets est de changer à terme la 
méthode de déclaration des paquets (actuellement archivelist*) pour :

- un automatisme pour les plugins Composerisés (présents sur Packagist) 
: une API publique à Packagist permet de lister l’ensemble des paquets 
de type "spip-plugin" par exemple 
(https://packagist.org/packages/list.json?type=spip-plugin). À partir de 
cela il est possible de récupérer une description de chaque paquet (dont 
le nom, la source, l’url de documentation, le zip ...) 
(https://repo.packagist.org/p/spipremix/saisies.json). Donc, de notre 
côté, avec un petit cron, il semble possible de découvrir 
automatiquement ces plugins SPIP pour les lister dans cet annuaire.

- pour les autres plugins, l’idée serait d’avoir sur plugins.spip.net un 
formulaire où l’on saisit l’url du projet (plutôt que de donner l’url du 
répertoire à zipper avec le n° de commit) : de donner l’url racine du 
projet (le git), ou sur la zone, le svn au niveau de la racine d’un 
plugin (_plugins_/saisies) en standard layout (tags / branches / trunk) 
et c’est l’outil qui génère alors un zip pour chaque tag, branche, trunk 
(lorsque la forge ne fournit pas d’api pour obtenir le zip) ; Donc sans 
indication de révision spécifique.

- en allant (beaucoup) plus loin, dans ce cadre de la zone, cet outil 
pourrait servir à transformer des plugins non standard layout sur la 
zone en standard layout, voire faire la migration svn > git, pour les 
personnes donc qui ne sont pas à l’aise avec ces migrations.

Par rapport aux documentations
------------------------------

Je pense qu’il faut aussi tenir compte des fichiers 'Readme.md' qui est 
relativement standard lorsqu’un code source est mis sur github. Assez 
souvent aussi un répertoire doc/ ou docs/ est présent. Mais dans la 
mesure du possible, s’il y a un composer.json, l’url de documentation 
est indiquée (de même que s’il y a un paquet.xml).

Pourquoi demander (lorsqu’on déclare un plugin) de rédiger autre chose 
si une telle url est renseignée ? Enfin ça mange pas de pain, mais à mon 
avis il manque "La documentation existe déjà" dans les choix.

--

Beaucoup de 🌈 et de 💜
MM.
_______________________________________________
liste: https://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
dev: http://trac.rezo.net/trac/spip/
irc://irc.freenode.net/spip