Framavox

Action 1 - Catégorisation des plugins

Lupinacci Eric
Lupinacci Eric Public Seen by 31

Les catégories actuelles datent de 10 ans (et oui!) et ne paraissent plus aussi bien adaptées qu'à l'époque.
L'idée est de revoir cette catégorisation en partant éventuellement sur une logique à deux niveaux car les catégories actuelles peuvent être réutilisées parfois en niveau 1.

Cette action est prioritaire car le rangement de Contrib demande à avoir décider de cette liste de catégories.

Pour consulter et commenter les résultats :
- les catégories, le framacalc https://lite.framacalc.org/contrib-categories
- les affectations catégorie-plugin, le framacalc https://lite.framacalc.org/contrib-plugin-categorie

Lupinacci Eric

Lupinacci Eric April 12th, 2019 12:54

J'ai commencé à travailler dessus en faisant d'une part des statistiques (voir sur Plugins SPIP) et d'autres part une analyse plus approfondi de l'existant (Drupal, Joomla, Dotclear et Contrib).
Je me suis rendu compte que Contrib est assez en phase avec Plugins SPIP et apporte des sous-catégories assez pertinentes. Je me suis aperçu aussi que pas mal de plugins ont été affectés un peu n'importe comment ce qui rajoute à l'impression actuelle.

J'ai commencé sur une Google Sheet à mettre tous ces éléments et à revoir entièrement la catégorie Auteur. Je vais mettre ces éléments en partage en ouvrant la google sheet à tous les participants de cette discussion.

Y

YannX April 12th, 2019 13:51

J'ai la meme perception : la structuration est assez cohérente (sauf quelques secteurs devenus de véritables fourre-tout, ou bien à scinder) ; mais l'impression de désordre vient pour beaucoup de plugins mal-attribués (définir plus complètement dans le texte des secteurs+catégories leur contenu me semblerait un élément de "charte éditoriale" utile.
Mais
Dans une optique "trouver des solutions", il me paraitrait assez naturel de pouvoir disposer d'autres articles et/ou rubriques dans cette structure, par exemple :
- des solutions et astuces non mises sous forme de plugin,
- des témoignages et exemples de mises en oeuvre (ou des soucis),
- des articles "généraux" de synthèse et orientation entre les plugins,
- peut-etre des articles de conception-réflexion (qui pourraient etre co-ecrits /Wiki)

Lupinacci Eric

Lupinacci Eric April 12th, 2019 14:14

Oui il faut expliquer mieux le contenu d'une catégorie et surtout pourquoi on fait un choix et pas un autre car souvent l'alternative existe (auteur_syndic dans auteur ou dans syndication ?). Mais une fois le choix fait, l'exemple fait office d'explication aussi en ce sens qu'il faut continuer ainsi pour les autres plugins.

Il y a déjà 1250 plugins à ranger, je me suis essayé sur une centaine pour l'instant en passant Contrib en revu pour cette centaine. Donc avant d'élargir le débat je pense qu'il faut se concentrer sur une proposition qui donne un meilleur résultat qu'aujourd'hui sur ces 1250 plugins. Ce que je vois en avançant dessus, c'est que si on met à part squelettes et thèmes, les catégories à revoir complètement sont divers, outil maintenance et performance. Les autres j'ai l'impression qu'il suffirait de les sous-détailler.

Y

YannX April 12th, 2019 15:11

Première proposition (origine .mm /Freeplane 1.7.6)

Lupinacci Eric

Lupinacci Eric April 12th, 2019 16:55

Je mets le fichier jpeg en attachement qui est suffisant pour l'instant.

RastaPopoulos

RastaPopoulos April 12th, 2019 17:13

Voui, pas besoin d'uploader un gros ZIP avec tous les exports imaginables

Lupinacci Eric

Lupinacci Eric April 16th, 2019 15:02

En fait, plus j'avance dans la revue des affectations actuelles dans le XML et dans Contrib plus je me dis que le premier problème qui donne une impression de mélange vient que beaucoup trop de plugins sont affectés n'importe comment soit dans le XML soit dans Contrib. Et souvent il n'y a pas de cohérence entre les deux affectations ce qui est quand même pas si difficile à faire !

Donc quoi qu'on décide pour les catégories il faudra veiller à être plus cohérent dans le futur et contrôler d'une certaine façon les affectations.

Maïeul

Maïeul April 17th, 2019 06:01

oui. D'où l'importance que l'arborescence corresponde. Et ensuite, un petit script de synchro régulière et hop !

cy_altern

cy_altern April 17th, 2019 08:09

sur ce point de la cohérence des affectations XML d'un plugin / arborescence de Contrib, je suis d'accord avec Maïeul: un script qui automatise la synchro semble utile...
Mais la question sous-jacente est de savoir comment ça se passe:
* la rubrique du plugin est elle automatiquement déplacée/crée au "bon endroit" de l'arborescence en fonction de ce que le script récupère comme info dans le XML?
* quid des plugins où le codeur a choisi une catégorie qui manifestement n'est pas la bonne?

Maïeul

Maïeul April 17th, 2019 08:13

   cy_altern a ajouté un commentaire sur: Action 1 -

Catégorisation des plugins
sur ce point de la cohérence des affectations XML d'un plugin /
arborescence de Contrib, je suis d'accord avec Maïeul: un script qui
automatise la synchro semble indispensable. La question sous-jacente
est de savoir comment ça se passe:
* la rubrique du plugin est elle automatiquement déplacée/crée au “bon
endroit” de l'arborescence en fonction de ce que le script récupère
comme info dans le XML?

je dirais oui

  • quid des plugins où le codeur a choisi une catégorie qui manifestement n'est pas la bonne?

ca fait partie lors du travail de validation éditoriale de valider ce
point (à mes yeux)

cy_altern

cy_altern April 17th, 2019 08:19

d'accord sur la validation éditoriale mais, en tenant compte du point 1 (automatisation du placement de la rubrique du plugin), ça implique que si tu veux déplacer un plugin dans l'arbo de Contrib il faut aller modifier son paquet.xml...
...ce qui n'est pas toujours possible (plugin pas sur la zone typiquement, ou sous git avec uniquement les PR autorisés...)

Maïeul

Maïeul April 17th, 2019 08:26

bien vu. Une solution alternative serait de faire un signalement plutot
qu'un déplacement (enfin dans un premier temps, je ferais des
dépalcement automatique, pour éviter de se taper 2 fois le boulot de
recatégorisation)

Lupinacci Eric

Lupinacci Eric April 17th, 2019 08:50

En fait, il y a plusieurs cas d'utilisation à prendre en compte.
1- Le développeur choisi une catégorie pour son plugin : elle nous parait cohérente avec l'existant, ça va, elle nous parait pas cohérente, il faut la changer dans le paquet.xml. C'est essentiel de le faire dès le début car cela a aussi une valeur pédagogique. Il faudra aussi décrire plus précisément comment choisir une catégorie, à savoir, quelle question se poser.
La question est comment on peut vérifier cela au plus tôt ?

2- Un utilisateur ou le développeur veut écrire sa documentation et on suppose que la catégorie est cohérente (sinon on retourne en 1- avant de continuer).

Si le plugin est déjà zippé, il existe dans la base de Contrib (spip_plugins). Il est possible de créer "automatiquement" la rubrique qui va bien, voire le premier article (principal) en s'appuyant sur un formulaire dans le public appelé par un bouton "documenter un plugin" et nécessitant uniquement le préfixe. L'utilisateur est renvoyé ensuite dans l'article pour rédaction. C'est le cas simple.

Si le plugin est pas zippé, il n'existe pas dans Contrib. On peut donc soit considérer que le plugin ne peut pas être encore documenté (mauvaise solution je pense), soit s'appuyer sur le formulaire de documentation qui cette fois demandera la catégorie et le préfixe pour créer au moins ce qu'il faut au bon endroit.

Ensuite, je pense qu'on peut développer un plugin Contrib tableau de bord qui va faire régulièrement des contrôles pour détecter des incohérences préfixe-catégorie ou permettre de remplir le nom de la rubrique-plugin voire son texte avec les éléments multilingues de la table spip_plugins. Je pense que cette notion de tableau de bord est à retenir pour ajouter aussi des contrôles sur les articles en cours depuis des années, etc.

RastaPopoulos

RastaPopoulos April 17th, 2019 09:46

Voui il est essentiel de pouvoir créer des rubriques de projet (plugins ou pas) dans la hiérarchie, même si ya aucun plugin empaqueté, puisque justement un des buts ça serait de plus facilement pouvoir annoncer un projet et montrer l'avancement du travail, conception, etc, même si le plugin n'existe pas encore.

Lupinacci Eric

Lupinacci Eric April 17th, 2019 11:40

Oui mais je suis toujours dubitatif à mettre tout dans l'arborescence des catégories. Mais ce n'est pas l'action pour discuter de cela, donc il faudrait basculer sur l'action de sectorisation de contrib.

Lupinacci Eric

Lupinacci Eric April 17th, 2019 19:06

Petit point d'étape après avoir visité un peu plus de 200 plugins sur 1250 et "traité" 3 catégories, à savoir, date, auteur et communication.

Le lien vers la Google sheet est le suivant : https://docs.google.com/spreadsheets/d/1DQsCdnjnM5Q4CB1hlZr1Zhww39ocXDTljZXHtj8IKpc/edit?usp=sharing
La vision simplifiée de la nouvelle proposition est dans la feuille "Proposition".
Le vision complète avec tous les plugins déjà traités et affectés est dans la feuille "Eric".
Ces deux feuilles ne sont pas modifiables mais il est possible d'y insérer des commentaires. Les autres feuilles sont uniquement consultables.

Je rappelle la legende de couleur de la feuille Eric :
- fond vert, documenté sur Contrib
- fond jaune, documenté en dehors de Contrib
- fond rose, non documenté

Je peux créer une feuille pour ceux qui veulent s'essayer à une autre proposition d'affectation des plugins. Sinon, je vous laisse commenter la feuille "Proposition" ici ou sur la feuille directement. Il est bien plus facile de critiquer un existant que de créer une arborescence donc profitez-en ;-).

Maïeul

Maïeul April 18th, 2019 15:28

je viens de regarder sur proposition, et j'ai mis quelques comnentaires. PAr contre, il manque des catégories, non? là j'en ai que 4 ?

Lupinacci Eric

Lupinacci Eric April 18th, 2019 16:51

Oui c'est ce que je dis dans mon message, actuellement j'ai fait date, auteur et communication et depuis hier j'ai pas mal avancé sur navigation. D'où les 4 ;-). Mais c'est longggggggg.

Maïeul

Maïeul April 18th, 2019 16:54

Oui, j'imagine. Désolé j'ai loupé cette info ;-)

Lupinacci Eric

Lupinacci Eric April 18th, 2019 17:30

Tout d'abord merci pour les premières remarques. Je trouve que tout Google qu'il soit l'outil fonctionne très bien. Maintenant pour améliorer l'efficacité de cette action qui est vraiment un pensum obligé je voudrais vous proposer quelques règles pour les commentaires.

1) Quand vous faites un commentaire, si vous êtes identifié comme "anonyme" signez au moins le message avec votre identifiant pour que je puisse savoir qui est au bout du fil.

2) Ne vous contentez pas de regarder la liste des catégories de la feuille "Proposition". Même si j'essaye d'expliquer et de fournir quelques plugins significatifs couvrant le panel de plus complet de la catégorie, rien ne vaut la vision complète des plugins inclus (feuille "Eric").

3) Si vous avez un doute sur un plugin, n'hésitez pas à lire sa description ou mieux à parcourir son article de doc quand il existe. Je le fait systématiquement et ça permet qu'on soit tous au même niveau de compréhension pour en discuter.

4) Evitez de me poser des questions trop ouverte comme "pourquoi?" et faites plutôt une proposition mais n'hésitez pas surtout, il est illusoire que j'y arrive tout seul. Rien n'est parfait loin de là mais si on veut boucler l'action il faut que j'arrive à passer tous les plugins dans un temps réduit (qui est bien inférieur au temps spipien qui est parfois celui d'un trou noir...).

5) Vous pouvez aussi vous amusez à faire une autre feuille avec tous les plugins comme la mienne (feuille "Eric"). Il suffit de me demander pour la création avec ou sans mes propositions.

6) Pour finir, il faut bien que vous ayez en tête mon heuristique pour créer cette liste. Elle tient en quelques points principaux :
- Je pars de l'existant XML et du classement dans Contrib si il existe. En général, j'essaye de pencher vers Contrib sauf quand je pense que c'est erroné ou incohérent avec mon approche.
- J'essaye de trouver l'objet principal du plugin en évitant de dire que c'est un outil car sinon tout devient outil en fait. Donc plus j'élimine d'outil mieux c'est, on pourra éventuellement retrouver cette info en tag (Contrib et/ou XML).
- Quand je commence à identifier un groupe comme navigation/motcle j'essaye de continuer à mettre les plugins "mot-clé" dans cette catégorie que ce soit des outils ou autres. En effet, je pense qu'un utilisateur préfèrera avoir tout ce qui concerne les mots-clés que d'aller dans 5 catégories pour le faire. C'est un parti pris mais la liste est construite ainsi.
- Enfin, je travaille par similitude, ce qui est subjectif mais cela permet de créer des groupes assez homogènes et d'une taille maitrisable. Je nomme cette catégorie mais finalement le plus important c'est la liste des plugins qui la compose. Renommer la catégorie, regrouper deux catégories ou aplatir les deux niveaux pourra se faire simplement après le premier jet complet.

Voilà, sur ce je continue :p.

RastaPopoulos

RastaPopoulos April 19th, 2019 11:40

Pour ce qui est de "outil" tout à fait d'accord. Je me suis fait une réflexion sur une heuristique sur ce point précis :

Tout ce qui concerne une fonctionnalité "interface" ou une fonctionnalité "intégrable" en squelettes (donc assez facilement, par des non-devs), devraient être autre part que "outil".

Et cette catégorie ne devraient contenir que des choses utilisables en PHP uniquement ou presque, par des devs (ça peut pour des libs JS aussi, si aucune intégration par défaut et qu'il faut dev du code pour l'utiliser).
Et inversement, un plugin qui parle d'un truc mais qui ne contient aucune intégration ni interface ni squelette, devrait être dans outil, afin de ne pas les mettre en avant.

Pour prendre des exemples (sans prendre de l'évident) : "sélecteur générique" qui intègre l'autocomplétion de jQuery, et bien il permet de l'utiliser facilement sans rien coder en PHP : on met un attribut sur un champ HTML et paf ça appelle une liste d'autocomplétion dessus (dont le contenu est fabriqué en squelette aussi donc assez facile). Donc ce plugin pourrait ne pas être dans "outil", mais dans "navigation" ou "recherche"…
En revanche "cvtupload" ou "saisies" ou "vérifier", c'est uniquement pour des dévs PHP, ça ajoute ou augmente des API et c'est tout. Donc ça devrait bien être dans "outil".

Lupinacci Eric

Lupinacci Eric April 24th, 2019 16:45

Etat des lieux au 24/03:
J'ai passé 300 plugins et les catégories (actuelles) auteur, date, navigation, communication. Il y a encore des trous mais je pense que je les comblerais en avançant.
J'ai pris en compte aussi les commentaires faits depuis le partage du fichier google.

C'est assez roboratif et j'ai besoin d'un coup de main pour relancer ma scrutation avec plus d'efficacité. L'idée c'est qu'en parallèle du travail exhaustif de révision des plugins que je réalise vous puissiez aussi élaborer une proposition de catégories à deux niveaux pour l'ensemble des plugins de façon plus empirique sans passer tous les plugins en revue. Je pourrais ainsi m'en inspirer quand j'affecte les plugins.
Par exemple, j'ai commencé ça dans la feuille "Proposition" avec les catégories Commerce et Administration qui ne sont pas encore traitées dans ma feuille Eric. Je pense qu'en combinant les deux approches on peut avancer plus vite.

Maïeul

Maïeul April 25th, 2019 11:59

je suis pas sur de comprendre exactemnt ce que tu attends de nous.

Lupinacci Eric

Lupinacci Eric April 25th, 2019 12:27

Moi mon message est pas très clair effectivement.

Dans la feuille "Proposition" de la google sheet, je construis petit à petit la liste des catégories sur deux niveaux à partir des affectations des plugins de la feuille "Eric". C'est une première approche.
Maintenant, c'est long et ça me demande d'imaginer à la fois la catégorie et à la fois l'affectation.

Donc je me suis dit que en parallèle vous pourriez, sans passer tous les plugins en revue comme je fais, imaginer la liste des catégories en suivant ce qui a été initié. Je l'ai fait par exemple pour Commerce, Multimedia et Administration (voir la feuille "Proposition"). Cela m'aidera à moins cogiter sur l'affectation ou a me donner des idées de catégories que je n'aurais pas sans ça.

Tu vois le truc ?

Maïeul

Maïeul April 25th, 2019 13:48

oui, je vois. J'essaie de voir si j'ai du tps samedi. sans garanti

Lupinacci Eric

Lupinacci Eric April 25th, 2019 17:19

Plus j'avance dans la revue des plugins et plus je pense qu'il faut totalement éliminer la catégorie outil au niveau 1 et la retrouver uniquement au niveau 2.

Par exemple, des outils comme N-Core ou le noiZetier devraient plutôt se retrouver dans InterfacePublique/Outil.
De même, pour les outils type API dont tu parles comme Prix. Je pense que Prix devrait finalement se retrouver dans commerce/outil.

A réfléchir et discuter mais je pense que si on ouvre un outil ou divers au niveau 1 on arrivera jamais à maitriser l'effet poubelle.

Maïeul

Maïeul April 27th, 2019 12:45

ca me semble cohérent

RastaPopoulos

RastaPopoulos April 27th, 2019 13:25

Je remets ça rapidement en vrai message plutôt que IRC : je ne trouve pas ça bien de mélanger des vraies choses finales pour les end-users avec des trucs qui ne sont que pour les devs PHP. Ça ne s'adresse pas du tout aux mêmes personnes et les devs sont une minorité.

Moi je suis d'avis de cloisonner les choses qui ont à utiliser uniquement PHP dans les outils. Les choses pour les intégrateurices je les inclus dans les end-users.

Et par exemple le Noizetier c'est pas du tout un outil, ça fourni une vraie interface de gestion, etc, je ne trouve pas ça bien du tout de le mettre sur le même plan qu'un auter plugin qui fournit uniquement une API PHP, ça va être super confus pour les gens. Un de mes buts ça serait que Noizetier et n-core ne puissent justement pas se retrouver dans la même catégorie.

Mais faut que je continue de regarder tout, je n'ai pas encore le temps.

Maïeul

Maïeul April 27th, 2019 13:27

peut être qu'il faudrait distinguer "outils" et "API" ?

Lupinacci Eric

Lupinacci Eric April 27th, 2019 13:53

Le noiZetier n'est pas un squelette mais un outil pour fabriquer les pages du site. Donc le positionner en interface/outil me parait totalement justifié. La question est pour N-Core qui est sans conteste un outil pour interface mais qui s'adresse plus à un développeur qu'à un webmestre. C'est une notion (type d'utilisateur) qui n'est pas utilisée dans l'arborescence en cours de construction. On peut donc l'isoler comme tu le demandes ou on peut la fournir par un tag.
Néanmoins, ça ne me parait pas un gros souci de choisir plus tard surtout si on a la liste des outil-API pour développeur.

Lupinacci Eric

Lupinacci Eric April 29th, 2019 18:56

Petit up de l'action.

J'en suis à près de 700 plugins passé en revue mais j'en ai une petite centaine que je n'arrive pas allouer (à votre bon coeur). Si j'exclus les catégories Squelette et Thème actuelles (environ 240 plugins) il me reste environ 300 plugins à scruter qui font partie des catégories Divers, Outil et Edition. Pas les plus simples !

Vous pouvez continuer à laisser vos remarques que j'essaye de prendre en compte au fil de l'eau. J'ai rajouté une colonne "?" dans la feuille Eric qui indique avec un "x" que je me pose une question qui est inscrite dans la colonne "Commentaires". Si vous avez un peu de temps et d'envie je vous invite à passer les questions et à me donner votre avis. Attention à bien lire la feuille Proposition qui liste les nouvelles catégories.

Pour l'interface publique nous avons actuellement deux grandes catégories : squelette et theme. J'ai pensé regrouper tout ce qui concerne l'interface publique dans une catégorie de niveau 1 avec des sous-catégories :
- squelette
- theme
- outil (squelette et thème comme les switchers)

Qu'en pensez-vous ? Voyez-vous d'autres sous-catégories ? Avez-vous d'autres suggestions ?

Pour les plugins géo, carto, météo voyez vous une idée de regroupement et si oui lequel ?

Maïeul

Maïeul April 29th, 2019 20:42

sur la question d'interface publique, je trouverais dommage de perdre
les sous catégorie de squelettes (generalise, blog, etc). En terme de
pertinence de classement, ca aide pour des gens à trouver leurs
squelettes.

Lupinacci Eric

Lupinacci Eric April 30th, 2019 07:10

Euh on peut étendre la liste en faisant squelette-generaliste, squelette-blog... si c'est vraiment essentiel mais faut qu'on arrive à trouver une liste qui a du sens. Il y a parfois des squelettes pas très génériques. Ca t'irais comme ça ?

Petite question en regardant le découpage de Contrib, la dist c'est un squelette généraliste ou éditorial ? J'ai du mal avec le qualificatif éditorial pour un squelette.

JLuc

JLuc April 30th, 2019 08:12

Il y a des liens structurels forts autour des notions de squelettes et de thèmes. Il me semble que les thèmes sont regroupés en jeux de thèmes et les squelettes en jeux de squelettes. Il me semble que les thèmes d'un même jeu de thème ne sont utilisables qu'avec un squelette particulier, ou avec les squelettes d'un certain jeu de squelette particulier.
Vu cette étroite intrication, est-ce que mettre les thèmes et les squelettes dans 2 secteurs à part est la meilleure manière de faire ?
Quoiqu'il en soit, ce serait bien que les liens structurels qui relient thèmes et squelettes apparaissent dans la structure de la partie de contrib consacrée aux thèmes et squelettes, ou dans l'interface de cette partie.

Maïeul

Maïeul April 30th, 2019 08:44

oui, ok (par contre je sais pas si tu as vu, tu n'a pas répondu directement sous ma réponse, mais dans un nouveau thread)

Maïeul

Maïeul April 30th, 2019 08:46

Avant de répondre sur le fond, un petit point terminologique. l'exprssion "jeu de squelette" est problématique (comme squelettes d'ailleurs). En fait sur contrib on distribue des jeux de squelettes (la diste est un jeu de squelettes, sarkaspip est un jeu de squelette etc). Stricto sensu, un squelette c'est un fichier .html contenant des instructions. Du coup plutot que de parler de "jeux de squelettes" je parlerai de "famille de squelettes".

Après oui ce serait bien que les liens famille de squelette-famille de thème aiillent ensemble.

Lupinacci Eric

Lupinacci Eric April 30th, 2019 08:56

Oui et c'est bien pour ça que je trouve plus judicieux de faire une catégorie "interface-publique" (ou tout autre nom adéquat) qui contiennent les squelettes (au sens jeux de squelettes complets comme la dist), les thèmes (au sens thèmes applicables à un jeu de squelette donné) et les outils qui peuvent être des briques HTML (squelette) comme des noisettes, des frameworks comme bootstrap ou des switchers de thèmes.
A ceci on peut rajouter que l'on peut avoir plusieurs sous-catégories de squelette comme les blogs, les généralistes...

Pour le lien squelette-thème je pense que le mieux est un mot-clé ou champ extra pour les thèmes.

Maïeul

Maïeul April 30th, 2019 09:01

A ceci on peut rajouter que l'on peut avoir plusieurs sous-catégories
de squelette comme les blogs, les généralistes…
Pour le lien squelette-thème je pense que le mieux est un mot-clé ou
champ extra pour les thèmes.

ou une liaison objet-objet ? (hypothèse, je n'ai pas réflechi)

JLuc

JLuc April 30th, 2019 10:02

D'accord avec Maieul pour préférer familles de squelettes.

Lupinacci Eric

Lupinacci Eric April 30th, 2019 15:56

Euh mais pour désigner quoi ? Les squelettes de type blog ? ou le jeu de squelette dist par exemple ? J'arrive pas à suivre là.

JLuc

JLuc April 30th, 2019 16:09

non là j'ai seulement évoqué les rapports entre thèmes et squelettes

JLuc

JLuc April 30th, 2019 16:34

Sur ces points, c'est pas clair pour moi et ça me semble pas clair dans la galaxie SPIP.
- Il existe des "'jeux de thèmes", ou "familles de thèmes", qui sont des ensembles de thèmes qui fonctionnent avec un même squelette (ZPIP par exemple, perso j'en suis resté là)
- A priori les différentes familles de thèmes sont incompatibles entre elles.
- Mais j'ai le vague souvenir que certaines des familles de thèmes sont acceptées par plusieurs squelettes. Par exemple : les thèmes de ZPIP1 vont aussi avec ZPIP2 (j'en suis pas certain, mais ça se présente avec d'autres non ? Noizetier peut être ?). Ces différents squelettes acceptant une même famille de thèmes forment une famille de squelettes.
Comme je disais, c'est pas clair pour moi, et il me semble que la navigation ou la structure dans contrib pourrait contribuer à faciliter la compréhension de ces rapports, et le test et l'usage des thèmes et squelettes à thèmes.

Lupinacci Eric

Lupinacci Eric May 1st, 2019 10:10

Oui alors c'est exact que c'est un peu compliqué et pas sur à 100%. Les thèmes Sarka fonctionne avec Sarka ça c'est simple mais pour Z je ne suis pas sur qu'il existe vraiment des thèmes compatibles 100% avec plusieurs squelettes surtout que ceux-ci peuvent évoluer ensuite indépendamment.

C'est pour ça que je pense qu'il faut voir les choses plus simplement et finalement dans la logique d'un utilisateur : je cherche un squelette qui fait papa maman et une fois trouvé je regarde quels sont les thèmes qui lui sont compatibles. Et ça je pense que c'est la logique du public.
Dans le privé il faut faire encore plus simple en séparant squelettes et thèmes : je veux documenter un squelette, je vais là, un thème ici. Il faut juste assurer d'avoir un moyen simple (champ extra) pour lier le squelette à ses thèmes.

Pour info, je suis retombé hier sur un article que j'avais écrit avec Joseph sur les thèmes. Intéressant même si il date un peu : https://blog.spip.net/Evolutions-de-la-gestion-des-themes-sous-SPIP-3.html

S

SpipFactory May 1st, 2019 11:34

hummmm

je serais partisan a garder la catégorie squelettes ou jeu de squelettes avec des sous rubriques
car toute la doc spip a tendance a employé le terme
exemple spip.net
Lorsque vous installez SPIP, un jeu de squelettes est proposé par défaut. Il se trouve dans le répertoire squelettes-dist/, à la racine de votre site. Dès que vous modifiez ces fichiers pour les adapter à vos besoins, ou si vous voulez installer un autre jeu de squelettes, il convient de créer un répertoire nommé squelettes/ au même niveau. Pour plus de détails sur cette question, lire l’article Où placer ses squelettes .

pour les Sous-rubriques
Squelettes par défaut
Comprendre et exploiter les squelettes par défaut, ceux distribués avec SPIP, appelés « dist » et autres « reset ».
Squelettes pour blog
Squelettes pour carnet web perso : en 2 colonnes, présentation antéchronologique de billets que les internautes peuvent commenter.
Squelettes éditoriaux
Des squelettes plus spécifiquement adaptés à l’usage éditorial au sens classique du web (magazine, chronique, blog à plusieurs auteurs).
Squelettes généralistes
Des squelettes aux possibilités étendues, prévus pour être personnalisés, adaptés à des usages très divers, par exemple (non limitatif) typiquement les sites associatifs.
Squelettes spéciaux
Squelettes répondant à des besoins précis : annuaire, slideshow, iPhone, etc.

aprés pour les deux suivantes c'est pas la que j'irais voir mais plus ailleurs
Outils pour squelettes
Des outils pour aider à la création de ses squelettes, choisir et paramétrer des éléments de squelettes, etc.
Tutoriels pour squelettes
L’affichage d’un site sous SPIP est mis en forme par un jeu de squelettes. Un squelette ce n’est rien de plus qu’un ensemble de fichiers HTML, contenant du code HTML, des sélecteurs CSS/JS, et des boucles SPIP. Il va définir la structure mais aussi (...)

aprés est ce que les sous rubriques sont boien rangé je ne sais ....

attention https://demo.spip.net/
parle de théme et non pas de squelette ,il faudra harmoniser en fonction du choix retenu

JLuc

JLuc May 1st, 2019 12:41

Ok alors pour à peine simplifier on peut considérer que les jeux de thèmes sont des ressources propres à UN squelette.
Dans ce cas, AMHA il me semblerait plus clair que les thèmes de ce squelette apparaissent en sous-rubrique de ce squelette, puisqu'il n'est utile d'y accéder QUE lorsqu'on a déjà fait le choix du squelette.
(Et si jamais un autre squelette utilise aussi ces thèmes, il est facile pour lui référencer les thèmes du premier squelette pour y donner accés.)

Lupinacci Eric

Lupinacci Eric May 1st, 2019 12:53

Ouais je ne suis pas trop pour car c'est un peu bancal. Je pense que le privé doit être simple en structure donc systématique. Et mieux vaut faire ces liens dans le public où c'est vraiment là qu'on en a besoin.

RastaPopoulos

RastaPopoulos May 1st, 2019 14:12

Attention, je corrige/précise : il y a deux concepts : les (jeux de) squelettes, et les familles. Et les thèmes ne sont PAS attachés à UN jeu de squelettes, mais bien toujours à une famille ! Qui peut ne contenir qu'un seul jeu au final hein, et donc l'identifiant de la famille se retrouve être le même que le préfixe du jeu de squelettes. MAIS ça peut être plusieurs.

Par exemple SPIPr c'est une famille et son identifiant c'est "spipr". Mais dedans il y a "spipr_dist", "spipr_blog", "spipr_doc", et même le dernier sarka. Et oui oui : TOUS les thèmes compatibles avec la famille "spipr" sont censés marcher sur TOUS les jeux de squelettes de cette famille !

Donc il faut prendre ça en compte…

JLuc

JLuc May 1st, 2019 15:42

Oui voilà. Sur le site actuel, la famille spipr est assez clairement définie, mais peut être pas aussi bien les autres familles. Et concernant la famille SPIPr, si elle même est assez clairement définie, la liste des thèmes qui vont bien avec cette famille de squelette n'est pas, elle, clairement définie. Ce serait bien de rendre ça clairement compréhensible et navigable sans ambiguité. Les relations de dépendances entre thèmes et squelettes devraient structurer l'UI qui donne accés aux squelettes et aux thèmes.

Lupinacci Eric

Lupinacci Eric May 1st, 2019 17:24

On est bien d'accord là dessus et pour moi il n'y a pas de doute que ce lien doit apparaitre dans la page du thème et du squelette. Mais je pense qu'un champ extra famille_theme ou famille_squelette est suffisant dans le privé pour établir le lien. Il ne faut pas créer des catégories pour cela pour la bonne raison qu'on ne les connait pas par avance.

Lupinacci Eric

Lupinacci Eric May 1st, 2019 20:03

Est-ce que quelqu'un pourrait m'expliquer la différence entre un squelette "editorial" et un squelette "généraliste" ? Est-ce que cette distinction n'est pas superflue voire confuse ? Si le but est d'aiguiller les utilisateurs dans les rubriques de Contrib je ne vois pas comment distinguer ces deux types.

Ne faudrait-il pas les rassembler et n'avoir plus que généraliste, blog et spécial ?

RastaPopoulos

RastaPopoulos May 2nd, 2019 07:55

J'ai l'impression qu'il faudrait quand même faire la différence entre les squelettes qui sont orientés magazine/éditorial d'office, donc sans pouvoir trop personnaliser, notamment la page d'accueil par exemple, avec les dernières publications, ou ce genre. Et les squelettes réellement générique, que ce soit fait en noisettes ou pas hein, mais où tu peux quand même pas mal personnaliser, les menus, le contenu de l'accueil (qui avec noisettes, qui avec sélections éditoriales…), et donc pouvoir les utiliser aussi pour d'autres choses, vitrine d'assoc ou d'entreprise ou aussi magazine ou autre.

Lupinacci Eric

Lupinacci Eric May 2nd, 2019 08:08

Ok, je laisse comme c'est sur Contrib donc mais je ne peux pas vraiment avoir d'avis critique sur le rangement actuel car j'avoue que j'ai du mal à percevoir la différence parfois sur un squelette. Faudra que quelqu'un fasse une vérification.

A ce propos, la dist est un squelette généraliste ou éditorial ?

RastaPopoulos

RastaPopoulos May 2nd, 2019 09:19

Bé la dist est absolument pas personnalisable, je ne sais même pas si ça prend en compte Menus. Donc je dirais forcément éditorial, avec l'accueil qui est bloqué obligatoirement à afficher les derniers articles dans l'ordre antéchrono etc.

Lupinacci Eric

Lupinacci Eric May 3rd, 2019 08:54

Petit up du jour :
Je viens de passer les 1000 plugins visités. Il y en a une centaine que je n'ai pas su positionner dans l'arborescence et qui ont "z ??" en niveau 1. Il me reste les divers et outils à revoir et je pense que ça va être une grosse souffrance car ça va partir dans tous les sens.

Serait-il possible que certains d'entres vous revoient déjà les affectations proposées et la nouvelle arborescence ? Il y a une colonne "?" qui permet de repérer les affectations sur lesquelles j'ai un doute.

RastaPopoulos

RastaPopoulos May 3rd, 2019 09:21

Merci pour tout ce boulot de ouf. Là c'est chaud, journée travail forcément, et je suis déjà bien à la bourre avec mon problème de plombier. Ce soir je suis pas là, et demain aprèm et soir non plus. Faudrait que vois ça demain matin.

Lupinacci Eric

Lupinacci Eric May 3rd, 2019 11:29

Ouais te bile pas plus j'aurais avancé mieux ce sera pour tout réviser. Y a surement pleins de choses perfectibles mais ça commence à devenir difficile à les voir seul. Y a besoin de challenger tout ça.

Par contre, il faut prendre le temps pour avoir une vision d'ensemble de l'arborescence et des plugins car y a tellement de petites subtilités que rien n'est blanc ou noir. J'ai essayé de mettre le plus de commentaires possibles quand je n'étais pas convaincu ou que je ne savais pas, ça devrait permettre une révision plus rapide.

Lupinacci Eric

Lupinacci Eric May 3rd, 2019 12:10

Petit sujet de réflexion :
J'ai créé une catégorie Commerce avec trois sous-catégories, boutique, paiement (car il y a beaucoup de plugins) et outil. Je ne suis pas trop convaincu par ce découpage même si je pense qu'il est important vu le nombre de plugins de garder une catégorie Commerce.
En outre, il y a aussi des plugins qui s'occupent de gestion de projet, de remplissage de formulaires administratifs, tous plus ou moins liés au boulot au sens large.

Je me demande donc si on aurait pas intérêt à créer une catégorie "Activité professionnelle" avec une sous catégorie "e-commerce", une autre "gestion-projet", "gestion-affaire" voire d'autres à définir ? Qu'en pensez-vous ? Pour les noms tout est modifiable et améliorable.

JLuc

JLuc May 3rd, 2019 12:41

La notion de personnalisation est assez importante pour le choix d'un squelette et pour la manière avec laquelle on perçoit les squelettes. C'est une dimension beaucoup plus parlante pour le choix d'un squelette que cette catégorie "généraliste" qui pour moi ne veut pas dire grand chose. Et quand un squelette est personnalisable, c'est une motivation souvent importante pour le créateur de squelette: ça fait partie du projet central de ce squelette. Bref, cette notion mériterait d'être mise en avant.

JLuc

JLuc May 3rd, 2019 12:43

Certains squelettes ne sont pas du tout ou presque pas personnalisables, d'autres sur certains points seulement, d'autres développent à fond les possibilités de personnalisation. Ce degré de personnalisation pourrait éventuellement être qualifié (par un groupe de motclés par exemple).
Mais surtout, comme les squelettes hautement personnalisables forment une catégorie bien repérée dans la perception qu'on a des squelettes, il me semble que cette différence trés visible mériterait qu'une rubrique leur soit consacrée.

Lupinacci Eric

Lupinacci Eric May 3rd, 2019 14:13

Ok, tu proposes quoi JLuc comme catégories à la place de ce qui est proposé ? Tu peux faire une proposition alternative sur les 100 squelettes qui sont listés ça serait plus simple pour comparer ?

JLuc

JLuc May 3rd, 2019 16:04

Pas facile. Je ne connais que très peu des squelettes.
Pour définir cette rubrique "Squelettes très personnalisables", ça pourrait être "Squelettes dont l'utilisateur peut modifier de nombreux aspects de l'apparence et de la structure sans devoir coder"
J'imagine que dedans il y aurait Sarkaspip, Escal, Soyez Créateurs. Peut être d'autres.
Peut être aussi Aveline, le noizetier et d'autres plugins y auraient leur place aussi. Peut être que formellement ce ne sont pas des squelettes mais fonctionnement ça y ressemble : un plugin qu'on installe et active, et qui habille le site et les données, de manière paramétrable sans devoir coder.

Maïeul

Maïeul May 4th, 2019 12:16

oui, je suis d'accord. pas besoin de catégoriser.
la question que je me pose, par rapport à ces champs extras (en general), c'est est-ce qu'il vaudrait mieux pas les générer depuis paquet.xml ?

Lupinacci Eric

Lupinacci Eric May 4th, 2019 13:02

C'est à réfléchir au cas par cas oui.
Il me semble que j'ai mis l'url d'un article que j'ai écrit avec Joseph il y a longtemps et qui parlait un peu de ce sujet. A relire aussi.

Y

YannX May 4th, 2019 13:23

Bonjour,
Bravo pour le travail mis a disposition sur ce tableau....

Sur le point de la catégorie "Pro.." je suis plutot dubitatif ! En effet, ces découpages pourraient devenir rapidement incohérents avec les réflexes de recherche : par exemple les outils de paiement vont être utile pour les associations (gestion des adhésions, reglement des cotisations, des prestations...), quant aux outils de gestion (de ce que j'ai déjà survolé sur le tableau), on peut faire la meme remarque.... sans parler d'autres nouveaux objets editoriaux.

Est-il bien acté la façon dont l’équipe éditoriale devra éventuellement imposer un reclassement des plugins ?

Lupinacci Eric

Lupinacci Eric May 4th, 2019 16:48

Oui c'est possible mais rien n'est simple ni clairement détouré. Il faut accepter des approximations. J'ai essayé de scinder les boutiques et les éléments du processus d'achat (en particulier, le paiement) mais au bout du compte ça se recoupe et on sait plus où est quoi.
Je trouve ce regroupement en activité (sans pro) assez intéressant et à conserver.
Si on trouve mieux que e-commerce global je suis preneur mais attention toujours à vérifier l'affectation de tous les plugins concernés avant de proposer une modification.

Lupinacci Eric

Lupinacci Eric May 4th, 2019 17:09

Petit up du jour :

Toutes les catégories ont été revues sauf Outil. J'ai aussi enlevé pas mal de "z ??" que je n'arrivais pas à affecter il y a peu car la liste des catégories se complète et permet plus de souplesse aujourd'hui.

Pour finaliser rapidement j'aurais besoin d'un avis sur les outils. Si on crée une catégorie N1 "Outil" que verriez vous en N2 ? Sinon, si on avait une catégorie N1 "Dev" que verriez-vous en N2 ? Sinon, comment voyez vous cette logique d'outils sachant que pour l'instant j'ai créé des xxx/outil qui fonctionnement pas mal pour l'interface publique mais pas forcément pour les autres N1 ?

Autres sujets sur la liste en cours. J'ai eu pas mal de commentaires et je voudrais débattre ici des sujets suivants :
- Il existe une catégorie multilinguisme avec deux sous-catégories, navigation et traduction. L'affectation des plugins fonctionne bien mais il possible sans rien changer des affectations d'adopter une autre approche peut-être plus intégrée : multilinguisme/navigation deviendrait navigation/langue et multilinguisme/traduction deviendrait contenu/traduction. Je trouve ça pas mal voir mieux sauf qu'on ne voit plus la catégorie N1 multilinguisme, ce qui est dommage.
- Il existe une catégorie communication/antispam et une autre administration/securite. On pourrait intégrer les antispams dans administration/securite ?
- Dans quelle catégorie N1 pourrait mettre la sous-catégorie "geographie" ?

A votre avis ?

Y

YannX May 4th, 2019 17:37

Il me semble que le groupe Media pourrait s'entendre comme "objets structurés" (plus complet que l'ancien "Objets éditoriaux nouveaux"), en récupérant donc les objets Geo, les objets Jeux, les objets Biblio, voire à terme d'autres objets spécifiques et Extensions (formules chimiques, ..), mais pas les Logos (qui font partie à mon sens du Contenu editorial/rédactionnel natif SPIP depuis l'origine) puisqu'ils se generalisent sur tous les objets

Y

YannX May 4th, 2019 17:54

Je reviens pour conforter une réflexion aperçue auparavant : distinguer maintenance technique de la gestion éditoriale (ce qui aide les administrateur à gérer le contenu) ;
D'autre part, la sous-catégorie maintenance gagnerait sans doute à se découpler d'avec les possibilités d'interface/export/import (qui n'ont pas le même niveau d'utilisation) ;
Cela peut amener à revoir quelque peu les deux catégories Communication et Interaction qui ne me semblent différer que par des aspects techniques dans leur définition proposée (j'ai meme envisagé de regrouper les deux différement...), en etendant la distinction de gestion editoriale ....

Y

YannX May 4th, 2019 17:58

Enfin l'approche Formulaires = formidable me parait beaucoup trop restrictive dans sa définition : que fait-on de saisies, des api, de la fabrique, des divers selecteurs.... (et on va se mélanger avec des objets améliorés comme Contact avancé : fonctionnel ou technique ?)

Y

YannX May 4th, 2019 18:10

Pour répondre sur la question "outils", il me semble que c'est un type de sous-catégorie assez générique, que l'on va retrouver dans de nombreuses catégories : je le définirais comme "brique utile pour construire une solution" mais qui n'est pas aboutie en l'état, car le webmestre devra compléter du code pour mettre en oeuvre une solution opérationnelle adaptée.
J'en ai notamment vu le besoin dans :
- gestion éditoriale = le statut (n'apparait qu'à peine ?)
- gestion editoriale amélioration UX
- interactivité => saisies # formulaires (les outils selecteurs...)
- date / extension
- auteur / extension (pourquoi Jabber et pas Jappix ?)

et cela me fait apparaître une autre notion de "filtrage" (comme Accès restreint ou insertion de critères par pipeline) sur le contenu éditorial

Lupinacci Eric

Lupinacci Eric May 4th, 2019 18:13

Bof je suis pas chaud, je trouve ça que ça deviendrait un fourre-tout. En plus parler d'objet me gêne un peu car c'est le but de la catégorie "contenu" (hors objet spécifique comme les auteurs). En plus, geo, jeux, biblio... ne sont pas tous des objets au sens SPIP ni des medias.
Donc je n'y suis pas favorable mais j'attends l'avis d'autres membres.

PS: je propose qu'on discute d'un sujet soit dans le fil soit dans un commentaire de la Google Sheet mais je vais pas répéter mes réponses des deux cotés. Un peu de discipline stp, car le boulot est déjà suffisamment long et complexe. En outre, pour faire une proposition le mieux est de l'évaluer via l'affectation des plugins pour savoir si cela a du sens.

Lupinacci Eric

Lupinacci Eric May 4th, 2019 18:17

J'ai essayé de distingue la gestion éditoriale et la maintenance technique (dans le monde industriel, et pour moi les métros, on parle d'exploitation et de maintenance) mais au bout d'un moment je me suis retrouvé avec des plugins à mi-chemin. Je le répète aussi (ma réponse dans la GSheet), la séparation avec les statistiques n'est pas aisée non plus.

Donc ne me demande pas de faire un truc que j'ai déjà abandonné par contre propose une affectation si tu veux pour voir si elle fonctionne.

Y

YannX May 4th, 2019 18:17

Je vous soumets une approche alternative sur les squelettes (interface publique), basée sur les systèmes-familles (ce serait plutot matriciel d'ailleurs) :
- famille -dist + coloration
- famille Zpip + thèmes Garden
- famille Z / Ncore ?
- squelettes configurables (avec un N3 par sous-systèmes)
- jeux squelettes dédiés (limités dans les objets natifs)
- jeux de squelettes complets (a la manière de...WP désormais.?)

Mais je n'en suis pas beaucoup plus satisfait : l'idée est de choisir un système global.
Et puis, il faudrait pouvoir faire apparaitre "toutes" les noisettes ou pages publiques des divers plugins de toutes les autres catégories .........

Lupinacci Eric

Lupinacci Eric May 4th, 2019 19:18

J'ai déjà répondu sur les familles : ça n'est pas une bonne idée car la liste des familles n'est pas figée. Il faut gérer cet attribut autrement.
Pour 3 autres catégories je ne vois pas en quoi c'est plus clair que la proposition actuelle qui est calquée sur le rubricage de Contrib.

Y

YannX May 4th, 2019 20:25

Merci Eric,
Familles : clairement, c'est un groupe de "mot-clés" (un peu comme la compatibilité versions de SPIP, et je pense qu'il en faudrait un second groupe "objet-table" ).
mais j'ai renoncé à défendre cette idée des mots-clés qui me parait pourtant d'évidence !
J'ai pourtant recensé (au bas mot) une quarantaine de contributions et propositions sur l'usage des mots-clés dans Contrib [désolé je la gère sous SPN !] Et cela devrait "exploser" maintenant que la notion est généralisée en SPIP 3 !?!

Ta réponse me rappelle de m'interroger sur l'ajout de nouvelles sous-catégories..

Lupinacci Eric

Lupinacci Eric May 4th, 2019 20:36

Quitte à me répéter je n'ai rien contre les mots-clés mais je ne suis pas pour les utiliser quand il s'agit de créer une structuration de type technique. Les champs extra sont une meilleure solution.
Mais les mots-clés auront leur place dans le nouveau Contrib une fois l'organisation mise en place. Ils viendront donner une sémantique supplémentaire qui à mon avis viendra remplir les objectifs dont tu parles dans tes divers messages. Mais chaque chose en son temps.

Maïeul

Maïeul May 4th, 2019 21:28

par activité oui, la question de savoir si on met le commerce à part se pose.

RastaPopoulos

RastaPopoulos May 5th, 2019 18:25

euh personne n'a jamais dit que formulaire c'était que formidable

F

Francky May 8th, 2019 07:19

Oui et non Jluc, concernant les themes, ils sont bien fait pour un squelette particulier, mais si tu regardes le paquet ou plugin.xml tu verras qu'ils n'ont pas un "necessite" mais un "utilise", ce qui fait que théoriquement, il est possible qu'ils fontionnent avec tous les squelettes (ce qui n'est pas le cas).
C'est pour ça que techniquement, je ne suis pas certain qu'il soit possible de faire un rangement automatique des themes dans contrib :-(

Lupinacci Eric

Lupinacci Eric May 12th, 2019 16:55

Petit up du jour :

Maieul fait une revue complète des affectations. Cela va me permettre de compléter et d'affiner la liste complète. Toutefois, j'ai toujours besoin de réponses à mes questions posées il y a une semaine car j'ai besoin de finaliser au plus vite cette liste. Je les rappelle ici car il n'y a pas moyen d'épingler un message et le précédent a été enterré depuis le temps.

Pour finaliser rapidement j'aurais besoin d'un avis sur les outils. Si on crée une catégorie N1 "Outil" que verriez vous en N2 ? Sinon, si on avait une catégorie N1 "Dev" que verriez-vous en N2 ? Sinon, comment voyez vous cette logique d'outils sachant que pour l'instant j'ai créé des xxx/outil qui fonctionnement pas mal pour l'interface publique mais pas forcément pour les autres N1 ?

Autres sujets sur la liste en cours. J'ai eu pas mal de commentaires et je voudrais débattre ici des sujets suivants :
- Il existe une catégorie multilinguisme avec deux sous-catégories, navigation et traduction. L'affectation des plugins fonctionne bien mais il possible sans rien changer des affectations d'adopter une autre approche peut-être plus intégrée : multilinguisme/navigation deviendrait navigation/langue et multilinguisme/traduction deviendrait contenu/traduction. Je trouve ça pas mal voir mieux sauf qu'on ne voit plus la catégorie N1 multilinguisme, ce qui est dommage.
- Il existe une catégorie communication/antispam et une autre administration/securite. On pourrait intégrer les antispams dans administration/securite ?
- Dans quelle catégorie N1 pourrait mettre la sous-catégorie "geographie" ?

Merci d'avance

F

Francky May 12th, 2019 17:21

Concernant les outils, je pense qu'il faut faire une différence entre les outils qui ne sont que pour les webmestres et les outils pour tous, exemple, "cachelab" n'est sans doute que pour les webmestres, "simplog" est pour tous

Lupinacci Eric

Lupinacci Eric May 12th, 2019 18:08

Euh je ne suis pas sur que ce soit le bon critère. Par contre, Simplog n'est pas pour tous, car il est réservé au administrateur complet.

JLuc

JLuc May 13th, 2019 08:24

c'est trop dense pour que j'aie un avis, et tu as une vision bien plus globale que moi sur le travail mené. Pour ces interrogations, il me semble que tu pourrais faire des sondages sur les listes publiques. Non pour avoir LA réponse à la question, mais pour avoir des avis qui alimenteront et confirmeront ou préciseront certaines pistes - et précisera ce qui est rejeté aussi. En plus de contribuer à l'avancée du process, même indirectement, cela nourrira les liens avec la communauté et facilitera des participations ultérieures.
Mes avis lorsque j'en ai un :
- la catégorie "géographie" est du même acabit que la catégorie "date" c'est du géotemporel... mais je n'en tire aucune conclusion
- je trouve préférable de garder une N1 "multilinguisme" (pas éparpiller). Elle peut se compléter par des liens dans les textes des rubriques "Navigation" et "contenu"
- s'il y a assez d'antispams pour justifier une rubrique, je trouve qu'elle a bien sa place dans "communication"

Maïeul

Maïeul May 14th, 2019 07:53

  • je pense que les outils pourraient être des N2 pour chaque N1
  • sur la question du multilinguisme, je suis neutre
  • pour moi l'antispam et la sécurité c'est pas tout à fait la même chose, je vois pas l'antispam comme une sous partie de sécurité, je garderait à part
  • a t-on besoin de la catégorie géographie ? pourquoi garderait ton geographie et pas bibliographie?
RastaPopoulos

RastaPopoulos May 16th, 2019 12:26

  • Pour "multilinguisme", je suis d'avis que si une catégorie se retrouve à plusieurs endroits, c'est que ça montre qu'il y a un problème. Que ce soit une fois en N1 et une fois en N2 (comme là pour "navigation"), ou plusieurs fois en N2 dans plusieurs N1 différent. Seul le "outil" pourrait être l'exception à ça, mais pas pour le reste. Je serais donc plutôt d'avis de dispatcher.

  • Pour moi géographie ça va dans "contenu". Pour moi "contenu" ça doit recevoir au maximum ce qui concerne les contenus éditoriaux au sens strict, càd vraiment pour les contributeurs de contenus, donc pas au sens "objet spip" générique. Par exemple "Commandes", c'est un nouvel objet SPIP, mais ce n'est pas un contenu éditorial, c'est une brique fonctionnelle. Alors que la cartographie si, c'est un contenu en soi.

  • Je n'ai pas d'avis tranché pour les outils en N1 ou N2, mais en revanche, j'ai toujours un avis très tranché sur ce qu'on entend par là. D'après moi, au maximum, sauf super exception, les catégories réelles pas fourre-tout devraient avant tout permettre de trier les plugins qui sont pour les utilisateurs finaux. J'entends par "utilisateurs finaux" en premier lieu les utilisateurs de l'interface (rédacs, admins, etc) qui peuvent ne jamais toucher à du code. En deuxième, j'y inclus les intégrateurices, lorsqu'on parle d'une fonctionnalité qui peut être insérée facilement dans les squelettes du site. Ainsi d'après moi : TOUT PLUGIN qui ne génère aucune interface, et qui n'est pas utilisable directement dans un squelette ne DOIT PAS apparaitre dans la plupart des catégories. Les dévs sont une population très précise : 1)beaucoup plus réduite + 2)qui vient et sait chercher des choses précises (et qui souvent ne le fait même pas sur le catalogue de plugins, mais sur les listes de discussion, le SVN, etc) : les plugins/projets qui ne concernent QUE ces gens là, ne doivent pas être mélangés avec le reste. Les gens qui vont parcourir le catalogue de plugins, que ce soit sur Contrib ou Plugins, c'est avant tout le grand public, qui cherchent des fonctionnalités utilisables directement. Je ne dis pas "que" mais bien "avant tout", donc les projets pour les devs doivent bien y être mais clairement séparés dans des catégories dédiées.

Exemple : quand on est dans la rubrique "commerce", le plugin "prix" ne sert à RIEN pour les gens. Il sera de toute façon installé s'il est nécessité par un autre plugin. Mais dans les gens cherchent des fonctionnalités, ce plugin ne leur apporte rien du tout : c'est uniquement une API pour les devs, utilisable en PHP pour construire d'autres vraies fonctionnalités. Ce plugin ne devrait donc PAS apparaitre dans "commerce" d'après moi, pour ne pas faire croire aux gens qu'ils peuvent en faire quelque chose : ça pollue les listes, ça fait du bruit pour rien. C'est très mauvais pour l'UX si on part du principe (c'est mon cas) que les devs sont 20% voire moins des visiteurs, et que l'interface s'adresse en priorité aux 80%.

À l'inverse "Couleur objet" par exemple, pour que ça fasse quelque chose, il faut l'utiliser dans ses squelettes certes, mais c'est utilisable directement, tel quel. Ça fournit une ou deux balises et dès qu'on les met ça fait quelque chose directement : pour moi c'est bien end-user. Ce plugin n'est donc PAS un "outil" du tout. Mais plutôt "contenu/extension" : il étend le contenu existant.

Un autre exemple "Court-circuit" n'est pas un outil non plus. Déjà il fournit une interface d'admin, et ensuite quand on l'utilise il change très directement le comportement du site public, immédiatement. Les liens vers certaines rubriques ne pointent alors plus sur la même chose : c'est un plugin de "navigation/lien".

Bref, ma méthode est entièrement basée non pas juste sur la sémantique (prix a un rapport avec le commerce) mais avant tout par l'UX, par ce qu'on veut obtenir comme expérience utilisateur, au final, pour la majorité des gens. Ne pas mélanger ce qui concerne les end-users avec ce qui concerne les devs car deux populations n'ayant rien à voir.

  • J'ai un problème relativement similaire à celui du multilinguisme pour la catégorie "date". Et cela a un lien avec toute mon explication précédente. Dans ses deux N2, on mélange des choses end-users avec des choses qui ne font absolument rien quand on les installe. Peut-être faudrait-il totalement virer ce N1 et suivant les plugins : certains sont vraiment des nouveaux contenus éditoriaux, comme Agenda avec les événements, d'autres sont pour étendre des contenus existants (ajout de champ par ex), d'autres sont vraiment que des outils pour devs. Parfois carrément ailleurs "Organiseur" par exemple, ça n'est pas spécialement de l'agenda : ça sert à mieux travailler en groupe, c'est de la gestion de projet ! (et en plus ya de la messagerie, etc)

  • Dans contenu d'ailleurs, je verrais bien une différence entre les nouveaux contenus éditoriaux, et ce qui étant l'existant (que ça étende un objet précis ou une extension générique). Ça va avec le point précédent : au niveau UX, je trouve normal que "Agenda" qui est une nouveau contenu complet, ne soit pas listé avec un plugin "Date trucmuche" qui juste ajoute une date quelque part. Mais ça vaut pour tous les nouveaux contenus éditoriaux. Est-ce que s'il y avait une catégorie "contenu/nouveau" ou "contenu/autre" il y aurait assez de choses à y mettre ? (Agenda, Chapitres…).

Bon ces deux derniers points sont en réflexion en ma tête encore hein, c'est plus des questionnements (alors que les autres points d'avant sont clairs pour moi pour l'instant).

Et je m'arrête là pour l'instant car ça fait des heures que je suis dessus. :D

Lupinacci Eric

Lupinacci Eric May 18th, 2019 15:30

Bon c'est bien tout ça. On avance et Maieul a bientôt fini la revue complète.

Je propose donc de supprimer le multilinguisme en N1 et de créer navigation/multilinguisme et contenu/traduction. C'est un peu dommage je trouve car exhiber une N1 multilinguisme me paraissait sympa.

Ok, je transfère géographie dans contenu/extension.

Pour le reste je suis toujours dubitatif. Adopter ton heuristique revient à finalement en avoir 2, une pour les outils et une autre pour le reste des plugins. Ca a du sens mais j'arrive pas à être convaincu.
C'est pourquoi je proposerais qu'on finisse une version 1 de la liste sans prendre en compte la logique outil comme tu le proposes et qu'on fasse ensuite une revue pour comparer en transférant les plugins que tu juges outil.
Et on soumet ces deux listes à quelques personnes pour savoir ce qui leur parle le plus. je pense que la v1 vers la v2 ne devrait pas trop prendre de temps.

RastaPopoulos

RastaPopoulos May 18th, 2019 16:07

S'il y a assez de plugins de géographie, je trouve sûrement plus logique de faire une vraie catégorie mais bien dans contenu, donc contenu/géographie, plutôt que fourrer des milliers des trucs en vrac dans contenu/extension.

Surtout que "extension" pour moi ça me fait plus penser à un truc qui étend de l'existant. Alors que là on a des nouveaux objets complets comme GIS. Je veux dire tu penses à "GIS" ça fait pas du tout penser à de "l'extension", ou en tout cas pas uniquement (car on peut aussi l'utiliser pour lier à de l'existant, mais c'est un nouveau contenu en soi autonome quand même).

Lupinacci Eric

Lupinacci Eric May 18th, 2019 16:13

Oui, donc c'est fait, contenu/geographie

Lupinacci Eric

Lupinacci Eric July 25th, 2019 08:14

Cette action fondamentale touche à sa fin mais n'est pas totalement terminée.
Le plugin SVP Typologie a été développé et une première version aboutie est publiée sur Plugins SPIP.

Ce plugin permet de totalement déporter la gestion des catégories (et des tags) en dehors des fichiers XML et de SVP. Pour info, dans SPIP 3.3, la table spip_plugins a été débarrassée des colonnes categorie et tags.
Cela va permettre plus de souplesse quant à la mise au point des catégories et à leur affectation aux plugins. L'interface privée permet d'affecter une catégorie ou des tags à un plugin, de charger une liste de catégories ou un ensemble d'affectations, d'exporter ces listes pour maintenance...

En outre, en collaboration avec le plugin SVP API, les collections catégories, tags et affectations sont disponibles via une API REST.

Ces modifications vont donc empêcher de faire évoluer le site Plugins SPIP en SPIP 3.3 ce qui n'a pas d'incidence puisque la refonte de Contrib est censée traiter ce sujet.

Il me reste plus qu'à finaliser une première version des affectations plugin-catégorie avec la nouvelle liste des plugins pour conclure cette action. Je vais m'y atteler cette fin de semaine afin de proposer une démo ce week-end.
Il faudrait aussi qu'on décide comment faire une revue plus précise de cette affectation sachant qu'avec SVP Typologie, les modifications seront faciles à mettre en oeuvre.

Lupinacci Eric

Lupinacci Eric July 28th, 2019 13:14

Voilà j'ai terminé de remplir le tableau des affectations. J'ai déplacé les deux feuilles, celle des catégories et celle des affectations aux plugins, sur un framacalc dédié, un par liste.

Les url sont :
- pour les catégories, https://lite.framacalc.org/contrib-categories
- pour les affectations catégorie-plugin, https://lite.framacalc.org/contrib-plugin-categorie

La question est maintenant de faire une revue approfondie de ces deux listes afin de publier au plus vite cette nouvelle catégorisation. J'avoue ne pas trop avoir d'idée pour faire cette revue donc je fais appel à vos propositions. Il est essentiel que nous élargissions les relecteurs car le résultat est aujourd'hui le fruit du travail de Maieul et moi-même ce qui n'est pas suffisant pour considérer qu'il est validé.

Merci donc de nous aider à finaliser cette action majeure.