Framavox

Action 3 - Organisation des plugins

Lupinacci Eric
Lupinacci Eric Public Seen by 34

En supposant que l'on a répondu à l'action 2, l'idée à débattre et amender pour cette organisation - en supposant deux niveaux de catégorie - est la suivante :
- une rubrique par catégorie de niveau 1 comme auteur, communication... (liste à redéfinir). La rubrique possède un champ extra "catégorie" rempli avec l'alias (ie auteur)
- une sous-rubrique par sous-catégorie de niveau 2 comme auteur/extension, auteur/connexion, auteur/autorisation... (liste à définir). La rubrique possède un champ extra "catégorie" rempli avec l'alias (ie auteur/extension)
- une sous-sous-rubrique par plugin qui possède un champ extra "prefixe" rempli avec le préfixe dudit plugin.

Les rubriques-catégorie sont créées une fois pour toute et non modifiables manuellement (sauf le webmestre)
Les rubriques-plugin sont créées plus ou moins automatiquement et non modifiables manuellement (sauf le webmestre)
Tous les articles inclus dans une rubrique-plugin sont réputés décrire le plugin.
Les rubriques-catégorie peuvent posséder des articles qui décrivent des concepts liés à la catégorie.
En outre, Contrib devra passer son mode SVP en non-runtime et de fait contiendra toutes les informations de Plugins sans plus rien échanger.

Cette réflexion peut aussi être lancée mais son implémentation doit attendre les décisions des actions 1 et 2.

Lupinacci Eric

Lupinacci Eric April 14th, 2019 11:23

J'ai fait un petit essai en ajoutant les champs extra "categorie" et "prefixe" ce qui permet dans l'espace privé de mieux comprendre à mon avis où on se situe. Je joins les captures d'écran.

1) La liste des rubriques. Je n'ai pas tout modifié mais uniquement deux secteurs qui représente les catégories date et auteur. Voir les cercles rouges.

2) Le secteur "auteur" : on voit le fil d'ariane, le contenu de la rubrique qui contient la valeur auteur. Ensuite pour les sous-rubriques on voit les catégories "auteur/connexion", "auteur/extension"... Enfin sous la rubrique "auteur/extension" on voit les plugins avec entre parenthèses le préfixe.

3) Enfin la rubrique d'un plugin (Adresse Jabber) avec l'affichage de son préfixe. Ce qui est dommage c'est que le fil d'ariane n'affiche pas l'alias de la catégorie mais ça peut être fait facilement.

Y

YannX April 16th, 2019 07:47

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....

Maïeul

Maïeul April 18th, 2019 15:38

oki pour cette solution :)

Y

YannX April 18th, 2019 21:40

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

Y

YannX April 18th, 2019 21:41

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

Y

YannX April 18th, 2019 21:42

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

RastaPopoulos

RastaPopoulos April 19th, 2019 11:57

D'accord pour tout sauf un point :

une sous-sous-rubrique par plugin qui possède un champ extra "prefixe" rempli avec le préfixe dudit plugin

=> Les sous-sous-rubriques sont n'importe quel projet qui rentre dans la sous-catégorie, et ceux des projets qui sont des plugins ont le champ "préfixe" rempli, mais c'est donc optionnel suivant le projet. Et ces rubriques peuvent donc être automatiques ou semi-automatiques pour les plugins OU manuel quand le projet n'est pas un plugin (mais rentre quand même dans l'arbo principale).

Lupinacci Eric

Lupinacci Eric April 19th, 2019 15:59

Oui c'est possible mais j'avoue être toujours réticent à mélanger les projets en conception avec les plugins en production.
J'ai proposé de transférer les projets en conception dans l'arbo des plugins une fois le développement achevé en plugin ce qui permet de transférer l'arborescence complète en modifiant correctement les articles de conception pour ne pas les mélanger avec les articles utilisateurs à venir.

Mais c'est exact que l'approche que tu proposes peut fonctionner :
- on crée une rubrique projet x sans remplir le préfixe mais en l'identifiant par exemple dans le texte;
- on rédige des articles de conception (faut-il les tagguer "conception" ?)
- le plugin pouvant passer en production, on saisit le préfixe (ou on clique sur un bouton "Passer en plugin") et on crée un article "principal" en même temps que l'on taggue les articles existants en "conception" pour les identifier différemment.
C'est ce point qui me gêne si on ne trouve pas un moyen de s'assurer que ce sera fait.
Pour compléter le schéma on peut iconifier la liste des rubriques-plugin avec un icone plugin et les projets en cours avec un autre icone pour repérer ça plus facilement. Dans le dashboard dont j'ai déjà parlé on pourrait aussi faire un état des lieux des projets en cours et des projets récemment clos.

RastaPopoulos

RastaPopoulos April 19th, 2019 16:30

Oui, les articles de conception devraient être marqués de type conception immédiatement, c'est impératif. Car comme dit dans l'autre fil, ce n'est pas que pour l'intérieur de la rubrique-projet : ça vaut aussi pour l'accueil général du site.

À tout moment quand un nouvel article apparait, on doit pouvoir savoir de quel grand type il est, et l'afficher dans une liste différente. On ne doit pas afficher un article de conception (que ce soit pour un nouveau projet en cours ou une refonte) dans la même liste qu'une nouvelle doc d'utilisation, qu'un article principal d'un nouveau plugin, ça ne s'adresse pas aux mêmes. Donc ça vaut bien en permanence, dès qu'on crée l'article, que ce soit une nouvelle rubrique, ou un plugin déjà existant depuis longtemps.

Lupinacci Eric

Lupinacci Eric April 19th, 2019 16:51

En fait, j'ai un peu la même obsession depuis le début. Essayer de ne pas obliger à remplir un champ ou mot-clé pour chaque article qui soit impliqué dans l'organisation et la structuration de Contrib mais privilégier les rubriques beaucoup moins nombreuses.
Ne peut-on pas imaginer l'organisation suivante :
1) je suis dans une rubrique-plugin en "production" :
- les articles d'utilisation (normalement les principaux) sont directement dans la rubrique-plugin.
- les articles de conception sont dans une sous-rubrique identifiée comme telle (champ à définir)
- les articles d'actualité sont aussi dans sous-rubrique identifiée comme telle.

2) je suis dans une rubrique-projet (le préfixe est vide et le champ x défini conception):
- je fais des articles forcément de conception.
- je clos le projet dans un plugin : dans ce cas je crée la bonne rubrique-plugin avec le préfixe choisi et j'y transfère le rubrique-projet pour me retrouver dans la situation 1).

Ce qui est intéressant dans ce mécanisme c'est que l'on peut avoir une interface utilisateur pour s'assurer qu'on reste cohérent.

Une pièce à casser.

Maïeul

Maïeul April 19th, 2019 16:54

On peut avoir une interface pour s'assurer qu'on reste cohérent aussi
sans passer par le rubriquage. Et je dirais même, plus facilement, parce
qu'on déjà les outils techniques pour ca (champ extra obligatoire, ou
mot clé lié obligatoire)

RastaPopoulos

RastaPopoulos April 19th, 2019 17:12

Pour le 1) la plupart des plugins ont peu d'articles en tout, dans de très nombreux cas, yora quoi, 1 article de doc, et 1 article de conception peut-être. Ça parait sur-compliqué de devoir faire cette sous-organisation en plus à l'intérieur du projet, au lieu de juste ajouter un mot clé sur l'article.

Éventuellement, pour avoir moins de choses à typer, on peut partir du fait que tout ce qui n'a pas de type est une documentation. Et qu'on ne type donc que quand c'est de la conception, ou une annonce de nouveauté, donc carrément pas souvent.

De plus, avec la méthode de typer avec un mot (ou autre du genre), c'est la même méthode tout le temps, c'est à la fois beaucoup plus simple à comprendre pour les rédacteurs, mais aussi plus simple à manipuler dans les squelettes pour construire l'ergonomie qu'on voudra. Ya beaucoup moins de test à faire : ya le mot-clé "conception", c'est une conception, point. C'est pas dans un cas faut "deviner" que c'est conception parce que pas plugin fini, puis ensuite la méthode change et c'est en rangeant autrement, etc. Non, explicite et toujours la même manière. Plus simple pour tout le monde à mon avis.

Lupinacci Eric

Lupinacci Eric April 19th, 2019 18:02

Oui c'est une bonne remarque.
Par contre, deux choses :
- je pense qu'il vaut mieux préremplir avec utilisation plutôt que de laisser vide, c'est toujours plus simple à tester.
- je serais plus pour utiliser un champ obligatoire comme préfixe, par exemple, type_article, afin de laisser les mots-clés uniquement pour de la sémantique non obligatoire.

Après, un jeu d'icone ou de couleur ou autre pourrait être utile pour visualiser rapidement le type d'article en plus du libellé.
Bon encore un pas de plus. Je vais essayer de faire un résumé demain pour tenter une conclusion rapide sur ces sujets.

Maïeul

Maïeul April 19th, 2019 21:21

je vois deux avantages aux champ extra par rapport aux mot clé:
- en terme d'interface, c'est immédiatement lors de la rédaction
- en terme de requetage, et donc de filtrage, pas besoin de table de liaison > plus optimal

pour un site associatif on utilise cela pour étiquetter, et je trouve ca plus pratique

Lupinacci Eric

Lupinacci Eric April 20th, 2019 08:20

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.

RastaPopoulos

RastaPopoulos April 20th, 2019 10:41

Ç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.

Lupinacci Eric

Lupinacci Eric April 20th, 2019 11:21

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.

Maïeul

Maïeul April 20th, 2019 11:53

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

Y

YannX April 20th, 2019 15:18

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...

cy_altern

cy_altern April 20th, 2019 15:20

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

Lupinacci Eric

Lupinacci Eric April 23rd, 2019 07:28

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.

C

chankalan April 24th, 2019 06:38

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)

Y

YannX April 24th, 2019 09:04

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

Lupinacci Eric

Lupinacci Eric April 24th, 2019 11:32

Je ne comprends pas ????

RastaPopoulos

RastaPopoulos April 24th, 2019 15:06

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à.

Lupinacci Eric

Lupinacci Eric April 24th, 2019 16:09

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.

Maïeul

Maïeul April 25th, 2019 12:05

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

Lupinacci Eric

Lupinacci Eric May 5th, 2019 16:56

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é.

Y

YannX May 5th, 2019 17:16

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.

Lupinacci Eric

Lupinacci Eric May 5th, 2019 17:42

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 ?

Y

YannX May 5th, 2019 17:47

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...

Y

YannX May 5th, 2019 18:07

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 ?

RastaPopoulos

RastaPopoulos May 5th, 2019 18:42

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)

Lupinacci Eric

Lupinacci Eric May 5th, 2019 19:13

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.

Lupinacci Eric

Lupinacci Eric May 5th, 2019 19:28

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.

Lupinacci Eric

Lupinacci Eric May 5th, 2019 19:41

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 ?

RastaPopoulos

RastaPopoulos May 5th, 2019 20:25

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.

Maïeul

Maïeul May 5th, 2019 21:30

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

Maïeul

Maïeul May 5th, 2019 21:31

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.

Maïeul

Maïeul May 5th, 2019 21:35

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.

RastaPopoulos

RastaPopoulos May 5th, 2019 21:55

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

RastaPopoulos

RastaPopoulos May 5th, 2019 22:26

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.

Lupinacci Eric

Lupinacci Eric May 6th, 2019 07:29

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

Lupinacci Eric

Lupinacci Eric May 6th, 2019 07:49

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é.

Y

YannX May 6th, 2019 08:34

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

Lupinacci Eric

Lupinacci Eric May 9th, 2019 17:30

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 ?

Y

YannX May 10th, 2019 08:24

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.

Lupinacci Eric

Lupinacci Eric May 12th, 2019 16:50

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.

F

Francky May 12th, 2019 17:32

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 ?

Lupinacci Eric

Lupinacci Eric May 12th, 2019 18:06

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.

Maïeul

Maïeul May 14th, 2019 06:22

non pas d'objection, au contraire.

merci

JLuc

JLuc May 14th, 2019 18:59

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é !)

cy_altern

cy_altern May 18th, 2019 18:06

"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 ?

Lupinacci Eric

Lupinacci Eric May 18th, 2019 19:24

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.

cy_altern

cy_altern May 19th, 2019 15:17

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)

Maïeul

Maïeul May 19th, 2019 15:26

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

cy_altern

cy_altern May 19th, 2019 15:38

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

JLuc

JLuc June 25th, 2019 12:58

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.

Lupinacci Eric

Lupinacci Eric June 26th, 2019 07:14

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.

Maïeul

Maïeul June 26th, 2019 07:20

je suis assez d'accord

Lupinacci Eric

Lupinacci Eric July 25th, 2019 07:48

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.