Action 11 - Extension de plugins

Moi je préfère les sélections parce que c'est moi qui l'ai fait. :p

Non mais surtout qu'on peut aussi y mettre n'importe quel objet comme les grappes, sauf qu'on peut personnaliser titre et texte. Et quand il s'agit de sélection manuelle, c'est justement là que tu peux avoir besoin de texte libre pour donner un sens. Dire "Vous pouvez aussi aller voir ce plugin qui permet ceci cela en plus", et ça pour chaque élément de la sélection. Donc Sélections éditoriales me parait mieux que Grappes pour ça (et en plus c'est mieux maintenu non ?) :)

c'est je crois ce concept de titre personnalisable et texte modifiable,
et pas synchronisé avec les objets liés, qui me parait bizarre pour les
selection editorial.

Cela étant, je me demande si on devrait pas plutot avoir des liens A2A
ou O2O typé. Ca permettrait plus de cohérence, au sein de contrib, me
semble-t-il.

Mais reste la question de savoir si on indique cela aussi dans le xml du
plugin.

suite à la proposition d'Eric (sur la listes) de laissons tomber la catégorisation dans paquet.xml mais de garder cela uniquement dans le référentiel de plugin (ce que je soutiens), je pense qu'il faudrait avoir la même logique pour tous les plugin connexes.

Je verrais bien du coup, sur le referentiel de contrib, différents options pour relier un plugin à un autre dans une relation qui ne soit pas de dépendance / d'utilisation. Je vois, pour l'instant:
- extension de (et du coup, à l'inverse : est étendu par)
- remplace
- s'inscrit dans un chaine pour répondre à des besoins (je suis pas hyper convaincu de l'intutilié, mais en gros c'est pour relier par ex tout les plugins de l'API de nwesletter).

Je pense qu'il vaut mieux éviter les selections editoriales ou les grappes, il vaut mieux un truc fixe défini dans le workflow de documentation / referentil de plugin,

Le extension de me semble un concept incontournable éditorialement, que cet attribut soit ou non inclut dans le paquet.xml.
Cf pour exemple actuel les 4 sous-rubriques de Formidable (https://contrib.spip.net/Formidable), "Abonnements à des listes de diffusion", "Formulaire de participation avec Formidable", "Réponses commentées" et "Fusion de formulaires avec Formidable".
Point de vue rubricage j'imagine qu'on ne déroge pas à la règle générale: il s'agit de rubriques-plugins, à priori rangées dans la même catégorie que le plugin "maître" (Formidable dans cet exemple), mais il semble indispensable de pouvoir signifier que ce sont des plugins qui étendent les possibilités d'un autre auxquels ils sont totalement inféodé (concept très différent du "necessite")
Après, je dirais que ça n'est pas une grosse contrainte pour les concepteurs de plugins de gérer ce extension de dans leur paquet.xml. A l'inverse le déporter en tant qu'attribut (CE?) de la rubrique-plugin sur Contrib permet que tous les auteurs ayant les droits sur cette rubrique puissent l'ajouter si le codeur l'a oublié...

Euh... qu'est ce donc qu'apporte ce concept d' « extension » par rapport aux « necessite » déjà présents aux côté des « utilise » ?

necessite indique qu'un plugiin a besoin d'un auttre pour fonctionner. C'est une dépendance technique, Utilise indique qu'un plugin connaît l'existence d'un autre et peut en tirer profit, c'est une amélioration pour le plugin qui a le utilise. extension indique qu'un plugin apporte des fonctionnalités supplémentaire à un plugin. C'est une amélioration fonctionnelle.

formidable necessite saisie, mais n'étend pas saisie. C'est juste l'outil technique qui lui sert de base. Par contre "fusion de formulaire" ajoute une fonctionnalité à formidable : c'est une extension

Ok les exemples étaient nécessaires car sinon ça me parlait pas. Je vois mieux maintenant... mais l'absence de la visibilité de cette notion d'extension ne m'a jamais manqué dans mon usage de SPIP. Dans quelles circonstances penses tu que c'est utile ?

Hier par contre, j'ai été confronté à une difficulté induite par l'absence de visibilité des "familles de plugins". J'ai voulu installer zen-garden et avec mes souvenirs plus ou moins confirmés par la doc, j'ai vu qu'il fonctionnait avec zpip (j'étais un peu embêté car zpip est obsolète, mais j'ai eu l'impression qu'il ne fonctionnait pas avec z-core). Par contre impossible de savoir quels thèmes vont bien avec zpip. J'ai du en charger à l'aveuglette. Ça, ça me semble gênant car ça impacte un public débutant, peu outillé et particulièrement sensible.
Je met ça en rapport aec la notion d'extension car ici il faudrait la notion de "famille de plugins". Je ne sais pas s'il faut définir plein de notions spécifiques comme "extension" ou "famille de thèmes" etc, ou permettre des "grappes" ou "sélections" polyvalentes, avec un titre et un descriptif pour chacune de ces familles... "Plugins Z compatibles pour zpip et zen-garden", "extensions de formidable"...

Et lol à la réflexion je vois que même avec les exemples, la distinction entre "extension" et "necessite" ne me parle pas ! (d'où : dans quelles circonstances penses tu que c'est utile ?)

typiquement pour la famille formidable, c'est utile. Mais ca relève du
documentaire, pas du technique.

Ce terme d'extension me parait un peu confus même si il décrit bien le cas de formidable et de son orchestre, car c'est l'ancien terme des plugins. En fait, on a des "types de connexité" entre plugins :
- le necessite des paquet.xml qui est claire et net
- l'utilise des paquet.xml qui est bien moins clair car pas systématique puisque son but est d'abord de gérer le chemin.
- et les catégories.

A cela on peut ajouter d'autres types de connexité, comme un "lire aussi" mais je suis d'accord avec Maieul que ces autres types doivent rester éditoriaux. Et aussi je les limiterais : a-t-on besoin de plus qu'un lire aussi ? A réfléchir.

Je comprend la réticence à ajouter un autre élément structurel.
Mais le fait est qu'il y a une difficulté actuellement pour relier certaines documentation :
- sans l'article "Liste des squelettes HTML5Up" il n'y aurait que la recherche pour trouver les articles HTML5Up (pour autant qu'on sache ou imagine qu'il y en a plusieurs). Cet article existe car je l'ai créé, mais dans d'autres thématiques, il n'existe pas.
- comment savoir quels thèmes vont avec zen-garden ? Je sais pas et ça me semble critique pour ce plugin tant qu'il n'y a pas d'article les répertoriant - et il peut ne jamais y en avoir. Ou avec bank ?

Pour le moins le site peut afficher la liste réciproque des "utilise" et "necessite" : la liste des plugins qui utilisent ou nécessitent le plugin courant. Ça répondra à un certain nombre de besoins (voir les membres de la famille de "bank" par exemple)... mais pas à d'autres (pour HTML5up par exemple, il n'y a pas de dépendance structurelle).

A mon avis, il faut laisser les utilise et les necessite dans les paquet sans rien rajouter pour l'instant. Les autres regroupements dont tu parles sont possibles via du rédactionnel ou du rubricage (yc mot-clé). Mais franchement le jour où il nous restera plus que ça, je serais content !
Maintenant, une famille de squelettes c'est différent d'un écosystème de plugins comme bank et tout ce qui a attrait au commerce.

Je suis bien d'accord pour cette démarche d'un article général (cela fait longtemps qu'on caresse cette idée ave JLuc) : toutefois je perçois deux points à préciser :
- qui le gère et l'édite (ce n'est pas forcément de la responsabilité d'un admin.restreint d'un plugin / plusieurs pourraient vouloir y participer / et comment gérer l'harmonisation éditoriale)
- dans ce type de cas, on crée donc une sous-rubrique chapeautant les plugins sous le niveau 2 de catégories (en effet, imaginons que des spipeurs créent une deuxieme forme d'implémentation incompatible pour le meme groupe de foncitonnalités : en l'écrivant je m'aperçois que cela rejoint votre discussion sur les familles de squelettes.

Mais faire apparaitre les plugins "nécessités" (voire "utilisés") dans la page de plugin (dans un encart..) me paraitrait fort utile...
Par contre, je ne suis pas convaincu par des "suggestions d'extensions" automatisées...