Action 3 - Organisation des plugins

Oui tout à fait.
Le seul truc que je ne sais pas faire pour l'instant avec les champs extras c'est de personnaliser l'affichage dans le privé pour le contenu de l'objet concerné. Ca met un truc par défaut assez laid. Matthieu m'a parlé de vue de saisie mais j'ai pas essayé.
Si ça marche tant mieux mais sinon j'aurais bien vu un truc comme un fond spécifique appelé si il existe. Mais c'est du détail.

Ça dépend, si tu utilises une saisie existante (selection par ex), ya déjà la vue, et tu peux pas personnaliser la vue juste pour tel champ précis pour l'instant (c'est un todo de longue date des saisies ça). Si c'est une saisie perso bah là on fait ce qu'on veut pour la vue.

Ok pour un champ plutôt qu'un mot, peu me chaut sur ce point.

Par contre j'ai encore des doutes sur toujours rempli ou pas. Que ce soit pour les anciens trucs, ou pour les nouveaux, ou après un déplacement depuis le carnet par ex, enfin il peut y avoir plein de cas où on se retrouve par-ci par-là avec des articles dont ce champ ne serait pas rempli. Donc moi j'ai l'impression que dans tous les cas il faut prendre en compte dans les squelettes/l'ergonomie le cas où des articles n'ont pas ce champ rempli. Et pour moi ces articles seraient par défaut considéré comme "documentation" (utilisation). Et du coup en cascade, si de toute façon on doit géré le cas où des articles ne l'ont pas, ya pas forcément besoin de le remplir. Enfin je ne sais pas, je me pose la question encore sur ce point quoi.

Oui je me suis posé la même question par rapport à l'existant.
J'avoue que j'évite en général d'utiliser une valeur vide pour exprimer autre chose que l'absence. Ici le vide désigne utilisation ce qui est moins lisible et demandera surement des tests (items de langue calculés par exemple, valeur par défaut...).
Après est ce que vide=utilisation est bien la valeur par défaut et que donc on aurait pas besoin d'exprimer "sans type" ?
J'avoue que j'ai un peu les mêmes doutes. Je propose qu'on finalise le tour des articles pour décider, l'un ou l'autre m'ira de toute façon.

je suis d'accord avec l'idée que par défaut = documentation.

+1 pour la méthode champ extra qui par défaut (= vide) donne un article de documentation.

Intéressant ! Peut-etre penser ç une normalisation de la décoration de certaines valeurs-clés : un symbolisme pour catégories/sous-catégories, pour prefixe, pour nature (thème, plugin, squelette(*), prive+/-public), et une notion qui me paraitrait utile : les objets editoriaux utilisés dans le plugin (liste native + code : +natifs + tous + autres...)

(*) il n'est pas toujours clair d'identifier : un nouveau jeu de squelettes, des squelettes complémentaires pour un/des objets, les dependances (ex. Evenement /article publié),
quand on lit la doc => je vais souvent regrder le source pour comprendre....

Je refais référence a cette remarque pour l'action [regroupement des squelettes]

Je rappelle une remarque déjà émise (Rasta?) :
limiter les champs non-natifs dans Contrib !

Avec la réflexion découverte sur les mots-clés, je me rapproche de l'expression d'Eric initiant ce GA plus haut.

Bonjour, j'étais bien en accord avec les remarques venues sur ce fil, sauf les dernières...
A°/ d'une part, le type d'usage en champ extra qui donne documentation... : j'y vois deja deux limites :
- je ne peux que avoir un seul type d'information (comment traiter un article de documentation qui précise aussi les internes [objets et conditions])
- comment gérer après les articles de "contribution hors plugin" (qui debouchera peut-etre sur un plugin d'ailleurs)
B- utiliser la "pseudo-difficulté de l'interface de saisie native pour arbitrer le choix entre champ-extra ou mot-clé me parait pour le moins.... abusif ? Je comprendrai cela si nous étions en WordPress ou Joomla (car modifier l'interface de saisie est uen autre paire de manches), mais en SPIP !!! ? ? ? ? Si l'interface accessoire ne suffit pas, vous pouvez facilement je crois rajouter par un pipe la saisie a la forme que vous voulez.... comme un champ natif.
Non, je reste ciblé sur les mots-clés pour caractériser/tagguer des articles (ou d'ailleurs totue autre objet editorial). A part ce principe, qui conditionne les possibilités d'évolutions utltérieures (en particulier sur les recherches), je vous suis dans ces conclusions...

Tu continues à confondre les mots-clés thématiques et la structuration de Contrib qui va permettre de garantir son utilisation de façon pérenne et guidée.
Dans ce fil nous essayons de donner une typologie des rubriques et articles pour structurer le site. Le choix c'est d'utiliser des champs extra afin d'éviter de surcharger les mots-clés avec des groupes qui n'ont pas de sémantique "utilisateur" mais "technique".

Et cela n'est en rien une limitation.

salut,
désolé, je n'arrive que maintenant dans la discussion, mais j'approuve vos remarques totalement : les champs extras et le champ vide = documentation
:o)

A moins que la syntaxe simple de SPIP sache traiter les champs multi-valués
C'EST une limitation !

Je ne comprends pas ????

Il répondait à ton précédent sous-fil à priori dont la dernière phrase parlait de ça. @yannx1 tu as un bouton "Répondre" sur chaque message précis, c'est plus compréhensible si c'est pour répondre vraiment à un truc précis. (Et tiens pourquoi as-tu deux compte sur Frama, quand je fais "@" ya deux yannx et yannx1)

Sinon pour essayer de répondre : pour ce qui est de la typologie c'est structurellement une information unique pour un contenu. Un article est soit une annonce, soit une explication de conception, etc. Donc c'est complètement hors-sujet de parler de multi-valué pour ces informations-là.

Oui on revient toujours sur le même sujet. On est pas en train de faire de la sémantique sur les rubriques ou les articles mais de l'organisation.

il me semble qu'on est arrivé à un consensus ici.

Petit up pour les actions 2, 3 et 8:
J'ai créé un Doc Google dont le lien est fourni dans la description du groupe. Le but est de regrouper les résultats des diverses actions et de rédiger des éléments de conception pour la réalisation de la refonte. Je vous invite à le lire surtout si vous avez pas suivi tous les échanges mais aucun commentaire n'est demandé.

Tu veux dire, les discussions c'est pour débattre d'un point particulier, et prendre une décision, et le document google c'est le doc de référence ?

Là pour le coup il s'agit juste d'un texte avec des chapitres (pas comme le tableur où apparemment fallait des trucs compliqués). S'il y a moyen d'avoir ça sur un pad plus léger, et surtout pas en allant sur google à chaque fois, ça m'arrangerait.

Surtout que contrairement au tableur, je vois encore moins l'intérêt de disperser les commentaires en en ayant à la fois dans le document et les débats ici dans les discussions. Là ça repart dans trop d'outils, sans avoir les débats au même endroit.

Du genre https://demo.codimd.org/VXSg33bnRh2xgsuUT32Mfw
(reste juste les tableaux à remettre en markdown)

Non je veux rien dire, j'ai juste rassembler des idées éparses pour pouvoir les confronter et vérifier la cohérence. Ca m'a permis de me poser de nouvelles questions et de trouver des trous dans la spécification.
Avant de commencer à coder un plugin "Contrib" pour implémenter/maquetter ces modifications j'avais besoin d'une doc à suivre. Le problème des fils c'est qu'au bout d'un moment on ne sait plus trop ce qu'on a dit ou alors il faut tous les parcourir pour le savoir. D'ailleurs Maieul ne se rappelait plus qu'on avait décidé d'utiliser la chaine vide pour désigner le type d'article "utilisation" par défaut.

Je pense franchement que c'est utile en tout cas pour moi mais si tu préfères que je ne le partage pas j'ai pas de souci. Après, comprends aussi que je passe pas mal de temps sur le sujet et que je préfère ne pas m'emmerder avec des outils que je ne connais pas ou qui vont me demander un apprentissage supplémentaire (markdown c'est bien mais c'est plus chiant pour moi). Et ces deux outils Google sont vraiment très performants pour le travail collaboratif et pour l'instant je suis un peu le seul à rédiger.

Tu ne crois pas ? En tout cas si tu as du temps je préfère que tu répondes aux questions que j'ai posé sur la liste des catégories. Et dis moi si tu veux que je vire le GDoc.

Ok, alors je pense clairement qu'il y a un soucis d'utilisation des résumés en haut de page.

Car qu'il y ait un document de référence à rédiger à plusieurs dans un pad, ça je peux le comprendre : c'est très exactement ce qu'on a fait pour la Charte. Discussion ici, et rédaction à plusieurs dans un pad permanent. Si à un moment on doit vraiment faire ça, et qu'il s'agit de rédiger juste du texte hiérarchisé, oui je suis totalement pour aller partout sauf sur Google, qui n'a absolument rien de particulièrement plus performant pour écrire un texte à plusieurs qu'un pad bien plus léger (au contraire, c'est hyper lourd, et bloquant, et encore pire quand on est sur Tor).

Si en revanche il s'agit pour chaque point important de savoir où on en est, de savoir les décisions finales qui ont été prises : ce n'est pas juste que c'est "mieux" de le faire ici : c'est juste obligatoire normalement, d'après moi. Toute décision prise devrait se trouver écrite explicitement dans le texte en haut de la discussion afférente. Quand une décision a été prise, à aucun moment on ne devrait avoir à relire la discussion pour savoir (ça sert seulement quand on veut l'historique du débat et des arguments). Donc je ne suis pas spécialement pour fermer les discussions, ou dans tous les cas, qu'on ferme ou pas (ça c'est juste du rangement, on accède toujours avec un bouton), il faut reporter les décisions en haut, toujours, pour chacun des sujets. Et avec ça je ne vois pas comment on pourrait louper un truc, au contraire : c'est pas éparpillé et on a déjà bien rangé en sujets cloisonnés très clairs.

En fait les fils qui permettent de sérier les actions sont pratiques mais ne permettent pas d'avoir une vision globale du système en cours d'élaboration. Quand tu intègres tout ensemble tu peux tomber sur des manques aux interfaces.
C'est une pratique habituelle chez moi de rédiger ce type de document qui me permet aussi de me replonger rapidement dans un sujet après coup.

J'ai donc modifié le libellé de tête en disant que c'était juste une sorte de résumé pour ceux qui veulent se remémorer les résultats de cette façon et j'ai nettoyé aussi le message du dessus pour qu'il n'invite pas aux commentaires. Si ça te va je laisse sinon je vire tout mais je pense que je continuerais à l'alimenter de mon coté.

Je sursaute en lisant :
"En outre, il pourra être possible de plaquer le rubricage sur celui du secteur “Plugins” niveau 1 ou 2. Une fonctionnalité de transfert du Carnet Wiki vers Plugins devra être proposée. "
Cela indique clairement que la distinction en Carnet ne correspond qu'a un statut d'édition particulier, entre 'archive', 'prop' et 'publie' !
Si on rajoute les rubriques "Projets" ou "Chantiers" chères à Rasta /moi aussi/ on pourra encore plus facilement gérer la mise a disposition d'informations a tous les visiteurs, en jouant sur le/les statut(s) proposés...
Alors pourquoi vouloir "dupliquer" le travail.... ?
D'autant que les astuces actuellement en Carnet pourraient alors venir compléter l'information...

Allons jusqu'au bout du statut....

Utiliser le statut permettrait aussi de faciliter :
- l'écriture collaborative (comme le wiki)
- la "modification-nouvelle version" [cf. le plugin Gizeh-like] d'article publié (des pedzouilles qui attendent, des ajouts qui trainent dans les commentaires...)
/sans perte de versionning entre les deux rédactions/

Le "MAIS" ! j'en vois déjà un, c'est que la gestion étendue des statuts n'est -à ma connaissance- pas encore très répandue dans les usages de SPIP.

Franchement j'en ai rien à faire du Carnet si tu veux mon avis. Si tu connais la Taverne ou que tu lis ce que j'écris dans le GDoc tu comprendras que ce n'est pas une méthode de travail qui me convient.
J'ai formulé cette idée parce que j'imagine que les sujets vont surement être connexes à ceux des secteurs-plugin mais d'ailleurs je pensais juste au niveau 1. Mais je vous laisserez volontiers la main sur ce secteur que je n'utiliserais jamais ;-) !

Après il faudra m'expliquer pourquoi une liste d'astuces si elle est bien écrite est un article du Carnet ou pourquoi des plugins zippés référencent encore une documentation du Carnet ?

Pour repondre à ton interrogation Carnet (ou Smellup) me semblent mélanger deux aspects de documentation autour de SPIP :
- la possibilité d'écrire et diffuser rapidement un article/informations sur un point particulier de SPIP, sans attendre 'le bon vouloir de l'équipe éditoriale' (ne prenez pas cette phrase pour une attaque ; je suis parfois aussi 'a la ramasse' en tant qu'administrateur pour publier un article proposé).
- la possibilité de co-rédaction qui enrichit sans cesse certains articles sur SPIP dans le Carnet...
Je ne citerai comme exemples que les nombreuses pages lancées par JLuc : quel dommage que ces infos & astuces (parfois transverses) ne soient pas accessibles facilement dans Contrib /j'ai mis/perdu des années à les trouver/...

Effectivement ces deux pratiques (de plus en plus habituelles, et AMHA nécessaires à la vie de SPIP) rentrent en contradiction avec l'exigence de perfection rédactionnelle défendue par l'équipe éditoriale (avec de bonnes raisons aussi) ....

Peut-etre avons-nous oublié de nous interroger sur les raisons qui conduisent de si nombreux spipeurs à avoir leurs propres articles et sites, avec plein d'informations que nous apprécierions de retrouver plus facilement dans les sites de la galaxie [je ne pense pas que ce soit seulement pour privilégier son propre référencement personnel, ni pour des raisons pécunaires ...].
Quels sont les obstacles à partager ses infos sur Contrib (qui garantit pourtant une certaine pérennité) ?
Personnellement j'en avais vu un au moins en 2011, qui m'a fait rebondir sur l'initiative SPN de B.Blazin : le ressenti d'une structure trop "fermée" de Contrib pour accueillir une extension de documentation qui s'est structurée progressivement...

Peut-etre d'autres pour d'autres pistes ?

Je peux comprendre tout à fait que tout le monde ne soit pas en mesure de rédiger un article parfait et préfère gribouiller quelque chose en se disant que c'est mieux que rien. Maintenant, fais de ton coté le travail que j'ai réalisé sur les plugins et tu verras peut-être les choses un peu différemment.

Déjà faut se poser une question : pourquoi rédiger une documentation sur une contribution qu'on a déposée sur la zone ? Pour partager ou pour se rappeler comment l'utiliser ou comment il est conçu ?
Si c'est pour partager le minimum c'est de se poser la question du besoin de l'utilisateur et de vérifier qu'on y a répondu. Sinon, ça sert à quoi ?
Donc mon avis est que la qualité de la documentation c'est le minimum que l'on doit aux utilisateurs, sinon mieux vaut ne rien partager. Et quand je vois des plugins sans slogan, sans description et sans documentation je me dis que ce n'est en rien collaboratif mais plutôt opportuniste (je me sers de la zone comme dépôt).

Après, le cas des astuces qu'on veut partager ou dont on veut se rappeler c'est très bien de le stocker temporairement sur le Carnet. Mais une fois le coup de feu passé ne peut-on pas réfléchir à une contribution plus finie qui intégrerait le contenu éditorial ? Moi je me pose toujours la question de pourquoi le carnet ne se vide jamais ?

Enfin, je pense que sur ces points de vue je suis surement orthogonal à la pensée actuelle et quand je vois la documentation de Github c'est pas ce qui va me réconcilier avec cette tendance. Maintenant, pose toi la question de pourquoi les plugins de Cédric, Rasta, Tetue, Maieul et d'autres sont autant utilisés ? Crois-tu que ce soit juste la qualité du code ?

En conclusion, faites ce que vous voulez sur le Carnet, moi je m'occupe d'abord des plugins.

alors YannX: à ma connaissance l'équipe éditoriale répond relativemnt rapidement, surtout si on la relance. Par contre oui, elle ne publie pas tout ce qui passe, parce que justement son travail éditorial c'est de vérifier la qualité des articles. Si tu as besoin de prendre du tps c'est le carnet, et le carnet on sait qu'il y a pas de controle de qualité (d'ailleurs il y a un paquet d'article illisible dessus).

Ensuite, si quelqu'un veut proposer un complément de doc sur un plugin deja existant, rien n'a jamais empêché de le faire sur le secteur principal. Voir par ex les articles sur les traitements de formidable qui ont été écrit après coup. DOnc l'argument "le carnet pour complément de doc" est fallacieux. Le carnet pour ébauche de complément de doc ok.

C'est justement la structure bien cadrée de Contrib qui fait que malgré nos critiques (justifiées) sur le fait que c'est devenu un peu le bazar, ce site reste quand même assez lisible et surtout cohérent pour les articles publics, après tant d'années et tant de contenus, alors que SPN est totalement illisible et incompréhensible à part pour 3 personnes peut-être. :D

Concernant la typologie utilisée dans ce travail, j'ai deux remarques :
1- n'hésitons pas a parler de 'secteurs' pour les"rubriques-catégorie niveau 1 (secteur)" , cela simplifie l'expression
2- la typologie des articles me semble incomplète et inadaptée à l'objectif principal de cette refonte, qui est de proposer une meilleure lisibilité sur la documentation des plugins en particulier : explicitement Maieul a en tete cette préoccupation de pouvoir naturellement mettre en avant l'article de documentation principale du plugin (avec le souci des traductions en sous-jacent), et je partage cette exigence, car il n'est pas réaliste -à terme- de compter sur des numérotations ! Un article de conception (d'analyse) risque d'etre plus ardu (et décourageant pour l'utilisateur) que l'article général de présentation, ou bien le terme est malvenu ; par contre, cela me plairait bien de pouvoir trouver [voir écrire en rétro-ingéniérie] la compréhension interne des plugins sans etre obligé de parcourir tout le code, savoir rapidement les objets touchés ou créés, les pages disponibles.... [autre exemple Saisies (avec le carnet..) !]
De meme la notion d'actualité me parait très limitée ; d'ailleurs comment gerer le passage d'une version à une autre des plugins (pensons non pas à Zpip ->Z mais aux acces restreint, aux archives, aux saisies, aux Formidables/Formitables... et vous en connaissez surement bien plus que moi !).
Je suggérerais aussi un type article-exemple qui décrit un cas d'utilisation ou un retour d'expérience...

non, surtout ne parlons pas de secteur. Dans le monde SPIP les secteurs ont toujours désigné les rubriques de niveau 0

la question de la typologie des articles n'est pas lié à la question de l'ordonnancement. typiquement saisies à plusieurs articles de type "documentation" ca empeche pas de trier.

La problématique de l'article principal a déjà été abordée mais non encore décidée. Je l'ai d'ailleurs rappelé dans mon GDoc de résumé. Je ne suis pas sur que sémantiquement ça soit au même niveau que le type d'article, je serais même plutôt de l'avis contraire.
Après je t'avoue que j'attends un peu des idées pour pouvoir évaluer les possibilités et me faire une idée définitive.

Faut-il par contre multiplier ce classement avec exemple, tuto... Là encore je ne suis pas sur, il faut quand même éviter que ça devienne une usine à gaz car le rangement redeviendra anarchique si personne ne comprends ce qu'il doit positionner comme valeur.

Maintenant, c'est peut-être parce que je fatigue un peu mais les remarques incessantes pour faire autrement commence à me gonfler. Y a-t-il quelque chose qui t'agrée aussi ?

L'article principal, par définition il n'y en a qu'un. Donc plugin "article d'accueil", c'est fait pour ça, et ça ne fait que ça et c'est très bien.

Ah oui exact je me rappelais plus de ce plugin. Tu as raison c'est la meilleure solution.

Je ne sais pas comment gérer les traductions (et les suivre en espace privé) ;
mais ce sera à penser lors de la personnalisation de rubrique.html

J'ai commencé le codage d'un plugin Contrib destiné à mettre en place les autorisations, workflows et améliorations de l'espace privé. Si cela vous intéresse je pourrais créer un fil dédié pour donner l'avancement et aussi poser des questions.

Pour l'instant j'ai juste une petite question.
Le secteur-carnet est identifié par la configuration du plugin Autorité (espace_wiki).
Le secteur-apropos est identifié par la configuration du plugin Exclure Secteur puisque ce secteur est exclu des boucles standards (exclure_sect).
Je souhaiterais aussi distinguer le ou les secteurs-galaxie de façon simple. De fait, les autres secteurs seraient forcément des secteurs-plugin.
Je propose donc d'ajouter une petite config de Contrib (qui pourra éventuellement être développée plus tard) pour choisir ces secteurs-galaxie.

Pas d'objection ?

Avec un "utilise" sur les deux plugins précédents
pour que la config.Contrin valorise les trois valeurs de secteurs (histoire qu'on n'oublie pas la config. des plugins précédents) !
Bravo pour l'idée.

non pas d'objection, au contraire.

merci

Un petit up de l'avancement.

Comme je l'ai déjà annoncé, j'ai débuté un plugin destiné à mettre en place les mécanismes et les affichages de l'espace privé. Une spécification est disponible aussi dans le readme du plugin. Ce plugin est sur mon compte Github.

J'ai mis en place les trois champs identifiés dans ce fil, à savoir, catégorie et préfixe pour les rubriques et type_article pour les articles au travers de champs extras, avec les autorisations associées pour l'affichage et la modification. En parallèle j'ai développé aussi une petite API pour les rubriques afin d'encapsuler les accès BDD récurrents. Toute cela fonctionne très bien même si ça demande à être confirmé et peaufiné.

A partir du moment où ces champs sont en place il est possible d'améliorer rapidement et assez simplement les affichages des rubriques. C'est ce que j'ai commencé et que je vais vous présenter ci-après.
Globalement l'idée est de faire apparaitre les informations :
- type de secteur, à savoir, secteur-apropos, secteur-carnet, secteur galaxie et secteur-plugin (et donc identifier un secteur autre qui serait une erreur).
- la catégorie et le préfixe pour les rubriques des secteurs-plugin.
- des informations sur le plugin pour les rubriques-plugin (niveau 3).

La première vue est celle de la liste des secteurs :

La deuxième vue qui est celle d'un secteur plugin qui permet en un coup de voir, le secteur-plugin, ses sous-rubriques qui sont les catégories n2 (celles affectées aux plugins) et en ouvrant le bloc les plugins avec leur préfixe.

La troisième vue est celle d'une rubrique-plugin avec l'affichage du préfixe dans la couleur de la catégorie et la liste des articles. On voit aussi l'article d'accueil qui permet de matérialisé l'article principal. La typologie des articles n'est pas encore mise en place. Cette vue est à travailler encore, je pense qu'il faudrait rappeler dans la boite d'info la catégorie, la compatibilité SPIP. Le nom et le slogan du plugin devrait apparaitre aussi et la description du plugin devrait remplacer le descriptif existant (synchronisation automatique génie + bouton). Pour cela il faut utiliser le texte (description) et le descriptif rapide (slogan) de la rubrique.

Sinon, je renouvelle ma demande de répondre à mes questions sur les catégories des plugins. Maieul lui fait une revue complète des affectations.

Bonnes idées tout ça. Faut voir à l'usage surtout, mais voici mes résonnances actuelles. Je vais donc parler de ce que je vois là.

PAGE LES RUBRIQUES (N0)
- les icones des rubriques sont petites déjà, mais le détail "imprimé dessus" est encore plus petit. Peut être peut-on se passer du dossier, et que la lisibilité gagnera s'il n'y a que l'icone porteuse de sens (queue d'écureil, pièce de puzzle, etc)
- pour les couleurs des rubriques, je me demande si c'est pas toute la box rubrique qui doit être colorée (comme dans le public), mais peut être en testant ça s'avérera horrible.

PAGE UNE RUBRIQUE N1
- la redondance d'affichage entre le nom de la rubrique et son chemin, qui contient son nom, juste en dessous, donne un effet d'encombrement.
- visuellement il y a beaucoup d'infos dans chaque rubrique, et le "tout texte" me semble pas faciliter la lisibilité. Une plus forte structuration visuelle serait bienvenue.
- par exemple, discrètement alterner des lignes à fond clair et foncé comme dans les tableaux spip, ça aiderait la lisibilité
- il faudrait présenter les préfixes de manière typographiquement plus distincte, comme des codes car ce sont des éléments destinés à être manipulés en priorité par le code (et non plus à destination de l'humain, comme un titre).
Et de manière visuellement plus distincte aussi, peut être commeles "tags" ou les "étiquettes" habituellement (= dans un "badge"), et peut être alignés à droite.

PAGE RUBRIQUE PLUGIN
RAS (sinon faut refaire tout le privé !)

"Une spécification est disponible aussi dans le readme du plugin. Ce plugin est sur mon compte Github."
Ca à l'air bien ton plugin: tu nous mettrais le lien vers ton Github qu'on puisse voir le readme et suivre l'avancement ?

C'est ici : https://github.com/smellup/contrib.
Maintenant le readme tu peux aussi le lire sur le doc refonte que j'ai linké dans la présentation du groupe de travail.

Il y a un truc que j'ai pas compris, tu veux supprimer le bouton "creer une sous-rubrique", mais alors comment cela va faire le jour ou un plug aura un changement de x concernant sa version et que la doc doit être refaite, sachant qu'ils auraient donc le même prefix ? Il peut très bien y avoir sur la zone, 2 avec le même prefix mais une doc différente et un "x" différent ! Ne faudra t'il pas le plug https://plugins.spip.net/polyhier.html ?

Je vois pas trop le rapport avec la choucroute.
Un plugin, donc un préfixe donné, a une rubrique avec des articles dedans. On ne peut pas créer de sous-rubrique c'est tout. Après l'archivage des versions obsolètes sera fait d'une façon autre qu'actuellement, façon qu'il reste à définir.

J'ai peut être loupé une discussion mais je n'ai pas trouvé comment sera géré éditorialement le cas des sous-plugins (= plugins qui étendent les fonctionnalités d'un plugin existant): 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 comment va t'on pouvoir signifier que ce sont des plugins qui étendent les possibilités d'un autre auxquels ils sont totalement inféodé? (à priori le "necessite" du paquet.xml n'est pas suffisant pour signifier cette dépendance)

il y a une discussion spécifique pour cela https://framavox.org/d/HAkKjlCq/action-11-extension-de-plugins

je transfère la question sur la bonne liste: https://framavox.org/d/HAkKjlCq/action-11-extension-de-plugins/15
merci!

Suite à https://zone.spip.org/trac/spip-zone/changeset/115774, une discussion sur irc a abordé la question des "auteurs" et personnes "crédits", qui sont indiquées dans le paquet.xml, et les simples commiteux non crédités hormi dans leur commit quand les passerelles svn trac et git marchent bien.

On pourrait aussi envisager présenter qqpart une liste de tous les commiteurs même non crédités dans le xml.

Le crédit des commits est déjà dans les... commits. Et c'est très bien comme ça.

Je ne pense pas qu'il faille encombrer le paquet.xml d'informations déjà présentes ailleurs surtout pour satisfaire l'ego de quelques uns. Pourquoi ne pas rétribuer aussi les commits par des points qui seront transformés en cadeaux par notre sponsor !

Sans rire j'ai vu passer cette discussion, elle m'a effaré et je préfère personnellement me passer de tels commiteux. Je trouve cette approche philosophiquement déplorable même si elle est clairement dans l'air du temps et aussi une porte ouverte à tous les abus de commits (et on sait que c'est dangereux!).

Conclusion pour moi c'est non, mais je ne suis pas le seul à décider.

je suis assez d'accord

Un up un peu tardif mais j'ai passé pas mal de semaines sur SVP Typologie avant de revenir sur ce sujet.
Les principes de cette action sont tous mis en place dans un plugin Contrib développé sur mon github. Il reste plus que du tuning pour les autorisations de création de rubrique voire de l'ergonomie (logos...).
Je vais mettre à jour un site de tests fourni par nicod pour que vous puissiez voir un premier résultat rapidement.

C'est une première étape franchie, la question va être de réfléchir à comment on intègre petit à petit ces réalisations dans Contrib car il me parait pas optimal de faire un grand big-bang à la fin de tous les développements.