Framavox

Action 4 - Archivage et cycle de vie des articles et des plugins

Maïeul
Maïeul Public Seen by 42

Avant de rentrer dans le détails du comment techniques de l'archivage, il faut se poser deux questions, me semble-t-il

  1. L'archivage doit-il être automatique ou manuel ? Ou semi automatique ? Si oui sur quels critères
  2. L'archivage implique t-il:
    • une disparition des articles
    • une disparition des articles de la recherche et de la navigation sauf demande explicite
    • une simple mention

Le but n'est pas de trouver un mécanisme totalement automatique mais plutôt de faciliter l'identification des obsolescences avec des mécanismes de détection astucieux afin de les corriger.
Ce sujet ne concerne pas uniquement l'éditorial de Contrib mais surement les plugins (au sens paquet.xml, SVP, Composer).

JLuc

JLuc March 28th, 2019 21:06

Pour le 1) : une disparition des articles de la recherche et de la navigation sauf demande explicite
Mais avant de rentrer dans le détail du comment, on peut se poser encore une autre question : quels articles veut on archiver ?
- les articles qui ont un tag version< SPIP2 mais pas de tag SPIP2 ou SPIP3 ?
- les articles qui ont un tag version< SPIP3 mais pas de tag SPIP3 ?
- les articles déjà tagués "archives"
- d'autres articles ? lesquels sur quels critères ?

Maïeul

Maïeul March 28th, 2019 23:08

c'était ma question 1). Tu répondais à la question 2) là :-). Je n'ai pas de réponse

S

SpipFactory March 29th, 2019 06:58

Bonjour,
a) L'archivage doit-il être automatique ou manuel ? Ou semi automatique ?
Oui l'archivage doit être automatique (je pense a ceux qui devrais le géré; je suis foncièrement d'accord avec l'automatisme débrayable)

b) Si oui sur quels critères
* L'archivage ne doit pas faire disparaître des articles ne serais ce que pour mémoire (d'ailleurs cela permettrais aussi si besoin un revert )
* une disparition des articles de la recherche et de la navigation sauf demande explicite
( ok avec ça un peu a la plugin spip pour les versions, la on pourrais inclure une recherche dans les archives sur une simple mention)

c) je pense qu'il faut archiver tous ce qui ne rentre pas dans les version spip maintenu
* inférieur ou égal a spip 3 , puisque plus maintenu a partir de juin

d) les articles déjà tagués "archives"; peu être il faudrais voir ce qu'il y a dedans

e) lesquels sur quels critères ?
c'est la que je me dit est ce que les archives doivent avoir un menu de classification ou est ce qu'on balance tout dans une rubrique archives

je ne peu que proposer suite a mon utilisation, je n'ai vraiment pas de compétences en code

Lupinacci Eric

Lupinacci Eric March 29th, 2019 07:00

J'ai l'impression qu'un article sur contrib devrait avoir deux attributs (champs extra à priori) qui déterminerait sa compatibilité SPIP : branche min et branche max. On peut aussi envisager de lui affubler toutes les branches correspondant à l'intervalle précédent mais pourquoi s'emmerder alors qu'on sait calculer à l'affichage.
Je parle ici d'articles "non plugins", donc tous les autres. A l'affichage, les articles n'étant pas compatibles avec les branches maintenues devraient être explicitement marqués et voir exclus à la recherche.

RastaPopoulos

RastaPopoulos March 29th, 2019 09:07

Perso j'ai l'avis inverse :
- l'archivage ne doit pas être automatique
- donc sur aucun critère hyper précis, juste des choix humains en se baladant dedans, une fois qu'on l'a fait un seul gros coup là bientôt, ensuite ça ne correspondra plus qu'à un ou deux articles hyper rarement à déplacer de temps à autre, donc ya aucun besoin d'automatisme
- Contrib ne devrait pas avoir des champs en plus, mots-clés etc, ou en tout cas le moins possible, il y a déjà un automatisme sur Plugins (avec SVP pour l'instant, et plus tard avec Composer), il faut arrêter les doublons d'informations pour ce qui concerne les plugins
- les trucs archivés ne devraient plus apparaitre nulle part par défaut, faut faire le grand ménage, et à la limite il pourrait y avoir une case à cocher "Inclure les archives" dans la recherche (c'est une bonne idée effectivement)

Lupinacci Eric

Lupinacci Eric March 29th, 2019 09:29

Je ne sais pas vraiment à qui tu réponds, mais bon, je vais reprendre différemment ma proposition.

1) Je ne parlais pas d'archivage ni auto ni manuel. Et là je te rejoins, l'archivage doit rester une action manuelle décidée à un moment t pour des critères qui sont difficilement modélisables automatiquement. A partir de ce moment, l'article sort du domaine de consultation par défaut. Faut-il avoir un moyen de retrouver et afficher une archive surement mais ce n'est pas fondamental dans un premier temps.

2) Pour les champs extras ou autres dont je parlais le but est juste d'alerter l'utilisateur sur la fraicheur d'un article par rapport aux version SPIP maintenues voire à la version stable. Cette vision n'est pas assez visible actuellement dans Contrib et Plugins SPIP. Et là je ne parle pas des Plugins car j'ai un peu switché sur le fait de sortir les plugins de Contrib. Ca montre d'ailleurs qu'on devrait d'abord répondre à la question des contenus Contrib et Plugins avant de parler d'archivage de Contrib.

Maïeul

Maïeul March 29th, 2019 13:24

oui, il faut trancher sur la question des docs de plugins avant toute chose. Si on sort les docs de plugins de contrib, on aura largement moins d'infos. Cela étant, si cela reste dans contrib, on sait maintenant gérer correctement les champs d'info sur les versions avec une synchronisation automatique.

JLuc

JLuc March 29th, 2019 13:54

On est les champions des travaux manuels. Comme de mettre la borne sup pour la compatibilité SPIP d'un plugin à la version actuelle de SPIP même s'il n'y a aucune raison a priori que le plugin ne soit plus valable pour la version suivante : cela force à passer en revue 800 plugins à chaque nouvelle version même mineure de Spip. C'est abusif à mon avis. Il faut pas s'ajouter de travail inutile, et utiliser au mieux les précieux humains que nous sommes.
Alors pour les articles, il y a déjà des motclés spécifiques à contrib qui indiquent la comptabilité. Quand ces motclés sont déjà renseignés, on peut bien en tenir compte de manière automatique -- sachant que les motclés ont été ajoutés manuellement ! Ouf, ça reste humain.

Maïeul

Maïeul March 29th, 2019 13:59

les mots clés sont de moins en moins renseigné automatiquement. Pour ce
qui concerne les plugins, la compatibilité de version est
automatiquement synchronisée.

La question de la borne max de compat des plugins est autre. C'est une
politique de sécurité, sans doute un peu trop restricive.

JLuc

JLuc March 29th, 2019 14:36

Je ne parle pas des plugins mais des articles contributions. Ces articles ne sont pas reliés directement à un plugin et leurs motclés ne sont jamais renseigné automatiquement - pour autant que je sache.

Maïeul

Maïeul March 29th, 2019 14:41

oui, effectivement... mais ces articles sont marginaux (en nombre, j'entend)

RastaPopoulos

RastaPopoulos March 29th, 2019 14:54

À priori je suis absolument contre la séparation des "docs" de plugins des autres "docs" ou projet non plugin, pour les raisons plusieurs fois listées sur la liste et dans d'autres fils.

"Docs" entre guillemets car justement mon but depuis des années c'est que pour tout projet on puisse mettre d'autres choses que de la doc, au moins de la conception, et des actus, et que cette (seule !) distinction soit super bien pris en compte dans l'ergonomie, avec des blocs/listes différentes, mis en avant différemment etc.

Et donc TOUS les projets doivent être dans le même site, ça n'a aucun sens d'avoir enfin un site en mode "projet complet" (conception-doc-actu) si on doit faire ça à deux endroits.

Et il se trouve que ça fait plus de 10 ans que Contrib a déjà ces contenus (mais mal rangé, mal distingué ergonomiquement) et que tout le monde connait déjà ce site pour ces contenus. Donc ya pas de raison majeure de changer ça : juste mieux ranger, et meilleure ergonomie.

Y

YannX April 10th, 2019 19:44

Coté archivage : il y a deux sujets :
1- quand décider d'archiver ?
2- comment réaliser l'archivage ?
sur le second point, la réponse est claire : par un statut = plugin Archive
(j'ai fait toute une recherche sur les solutions et réflexions déjà effectuées)...

Cela s'applique aux articles de docs comme de plugins, sans "torturer" l'arborescence sémantique des rubriques....

Maintenant toute solution technique obligera à modifier ou rajouter des squelettes :
l'avqantage de cette approche est de n'avoir aucune interférence avec d'autres reventilations des rubriques, carnets et/ou mots-clés et il suffit de rajouter le critère publie ou archive (avec une case a cocher) pour ajouter l'affichage des archives sur demande. (cf Contrib/article 5108)

Lupinacci Eric

Lupinacci Eric April 11th, 2019 06:36

Non la réponse est pas si claire à mon avis. Il faut distinguer l'archivage ou nettoyage de la base actuelle et l'archivage à terme une fois le nouveau Contrib en service.
En effet, je ne suis pas pour laisser les articles obsolètes, à moitié écrits, ou non publiés encombrer le privé. Je serais favorable dans ce cas à supprimer ce qui ne sert à rien (articles ou rubriques) et qui peut l'être sans perdre ni historique ni contenu, et stocker dans une rubrique Archives (ou mieux) le reste qui a peut être valeur historique.
Et surtout j'arrêterais voire je supprimerais les dizaines de rubriques Archives parsemées dans les rubriques.

Après, une fois cela effectué, il sera important de définir un processus d'archivage qui pourra éventuellement utiliser Archive.

Y

YannX April 11th, 2019 08:22

Plus précisément (AMHA), il faut distinguer :
- archivage "système/squelettes" permettant de présenter des articles "actuels" aux premières demandes (et ajout d'une case pour recherche dans des articles archivés car à vocation historique)
- archivage "editorial" (géré à la marge par les admins), qui applique une politique editoriale formalisée et rédigée en commun (de façon à ce que plusieurs administrateurs puissent la co-appliquer).
La référence au privé est "une erreur normale" d'ergonomie, car le site est d'abord prévu pour etre visité et lu en public ! Mais, bien que a-normal, il est assez naturel aux administrateurs/webmestres/Spipeurs (très habitués à l'interface privée) de passer plus souvent par celle-ci [moi tout le premier !] ; simplement ce n'est pas une raison pertinente, au regard de la disponibilité du contenu ; je dirais meme au contraire que l'interface privée doit permettre d'avoir accès à toutes les pages de contenu possibles.
Mais effectivement, rajouter d'autres onglets de filtrage dans la page ?exec=articles permettra de faciliter certaines utilisations.
Une autre possibilité serait d'étendre le plugins "Mes Favoris" pour pouvoir rajouter une condition de filtrage personnalisée (fonctionnement sur le principe du filtrage par Zones d'accès restreint, c-a-d sur les requetes en bases et pas dans les squelettes)...

Pour le travail de suivi éditorial, j'avance peu à peu, déjà pour compléter certains libellés de rubriques ; quand des règles auront été posées, je pourrai donner du temps pour éditer les 4000 articles progressivement.... https://contrib.spip.net/ecrire/?exec=articles&debut_liste_art=-1&trisession_liste_art=statut&var_memotri=trisession_liste_art (exemple... ;-)

Maïeul

Maïeul April 18th, 2019 15:40

oui

F

fred May 6th, 2019 12:22

La question préalable ce sont les critères d'archivage.

Les questions de l'automatisation et de la destination des archives dépendent des critères d'archivage et des cycles de vie, qui eux-mêmes pourraient dépendre de la nature des documents :

Qu'est-ce qui fait l'obsolescence d'un article ? Y a-t-il des critères d'obsolescence différents, par exemple en fonction du secteur d'origine (catégories plugins / Galaxie SPIP / Carnet Wiki) et/ou du type d'article (conception / actualité / utilisation) ? Y a-t-il des critères communs ? ...

Peut-être faudrait-il donc reformuler l'intitulé de l'action en ce sens et dans cet ordre :

  • quel(s) critère(s) d'archivage, généraux et particuliers ?
  • quelle(s) destination(s) (archivage ou destruction, accessible ou non, en secteur ou en sous-catégories, niveaux ou statuts d'archive, etc) ?
  • automatisation(s) (aucune, partielle ou totale, différenciée...) ?
  • fréquence(s) ?

Sachant que, comme l'indiquait Eric, il faudra bien commencer par le nettoyage de l'ensemble de la base actuelle, dans son état actuel, c'est à dire selon des critères de ce fait peut-être spécifiques mais qui pourraient recouper ou déterminer ceux de l'archivage.

Il s'agirait d'abord d'après moi de faire une sorte d'état des lieux, de lister combien et quels articles de l'existant sont concernés afin de déterminer et d'affiner les critères définitifs, avant de décider ce qui doit être fait des différents articles mis de côté et de savoir s'il est souhaitable et possible d'automatiser l'archivage en totalité ou en partie.

Pour lancer la discussion sur les critères, avec cette première étape de ménage de l'existant à l'esprit, je proposais de fixer comme critère général minimal la sortie de SPIP 3, par exemple d'identifier les articles dont la

  • version de SPIP indiquée < 3, et/ou
  • date de dernière modification de l'article < sortie de SPIP 3, et/ou
  • date de dernier message sur le forum associé < sortie de SPIP 3, et/ou
  • date de dernière visite < sortie de SPIP 3, et/ou
  • ...

à voir si ces critères peuvent s'appliquer indistinctement à tous les articles ou en différenciant le traitement par futurs secteurs ou autre.

Y

YannX May 6th, 2019 16:33

Effectivement, reposer la question des critères est un bon point :
Je vais l'illustrer par quelques recherches que j'ai pu faire sur Contrib ces derniers temps, qui dépassent la simple approche "quel plugin ?".
Effectivement j'ai parfois une approche un peu moins commune, car j'apprécie de pouvoir comprendre les arguments de conception et les principes de mise en oeuvre (qui sont rarement expliqués dans l'article de présentation générale du plugin / obligeant chaque développeur voulant intervenir a refaire toute la rétro-ingénièrie...)
J'ai ainsi recherché des réflexions sur :
- l'archivage éditorial
- les usages de mots-clés
Je me suis rendu compte dans les deux cas, que si des plugins existaient, il y avait aussi eu de nombreuses contributions de type "astuce", exemple... ou simples réflexions, qui permettent de mettre en perspective les diverses solutions imaginées...
J'en déduit un premier principe :
-1. archiver ne veut pas dire supprimer, mais filtrer !
Donc une partie du travail sera à traiter dans le codage des squelettes.

D'autre part, de mon expérience d'administrateur éditorial sur divers sites de communautés, je dirais qu'il est plus pratique de "voir in-situ" le comportement, que de devoir le ré-interpréter d'après une gestion en privé (une numérotation des articles, des codes statuts ou des mots-clés par liste déroulant).
Cela m'amène à proposer une seconde piste de pensée :
2. le filtrage ne doit pas modifier l'organisation principale (qui pilote la recherche d'informations).

A titre d'exemple (que les "vrais-anciens spipeurs n'ont jamais eu a pratiquer -cela n'existait pas encore-, mais pensez à ceux qui abordent la "courbe d'apprentissage", très nombreux sur SPN et d'ailleurs certains m'écrivent/m'expliquent leur intéret, avant d'etre devenus autonomes avec programmer),
j'ai adapté un CocheMots dans l'espace public pour mieux "voir" la saisie des mots-clés.

Enfin, la recherche peut s'appliquer à partir de différents points de vues, de perspectives, eventuellement recomposées en expressions logiques ;
d'où un troisième guide de réflexion
3. les 'index' de sélection-accès doivent pouvoir être combinés.

En conséquence.... j'attends vos réactions et discussions !

Maïeul

Maïeul May 6th, 2019 17:01

Ma réaction: ton message est, comme dans 95 % des cas, incompréhensible.
Tu saute du coq à l'âne, ne relient pas tes phrases avec des connecteurs
, etc.

Enfin si la seul info que tu veux dire c'est que l'archivage implique
que les informations soient toujours là, mais filtrés par défaut.... je
crois qu'on tous d'accord là dessus. Si tu veux dire qu'il faut de la
recherche multicroisée, aussi...

F

fred May 6th, 2019 21:36

@maieul je vois que tu as modifié l'intitulé mais c'est pas logique :p

Ce sont les critères qui sont automatisables ou pas. On ne peut pas savoir s'ils sont automatisables avant de les connaître. Pas de bras, pas de chocolat.

(s'ils sont déjà connus je veux bien les connaître)

Maïeul

Maïeul May 6th, 2019 21:52

ah non j'ai rien modifié...

F

fred May 7th, 2019 06:43

alors c'était une façon d'insister de ma part ^

Maïeul

Maïeul August 25th, 2019 13:34

Je crois que vous les évolutions du projet depuis quelques temps, avec la fusion plugin-contrib, il me semble que le plus pertinent est
1) masquage lors de la rercheche / de la navigation des contribution (principlament plugin) qui ne sont plus sur une version de spip
2) et c'est tout

Z'en pensez quoi?

F

fred August 25th, 2019 18:07

Oui, on en revient à la proposition initiale d'Eric, la condition impérative serait d'obliger à l'avenir de spécifier des bornes mini et maxi, quel que soit le secteur et quel que soit le type d'article. Dans ce cas OK, ce serait possible de se contenter de ce critère général arbitraire d'archivage et même de l'automatiser donc.

Il reste cependant la possibilité voire la nécessité de différencier ou d'affiner le traitement en fonction des secteurs ou des types d'article, cf. mon message précédent.

Par exemple, le type article-actualite devrait avoir un régime d'archivage plus fréquent qu'un changement de version de spip… Ça peut être archivé à la main ou, mieux, automatiquement en fonction d'un période à indiquer, ce qui ne serait pas aberrant pour ce type d'article.

Maintenant je conçois que le bornage max soit un peu contraignant et casse gueule… m'enfin vu la fréquence actuelle des mises à jour spip, c'est pas non plus rédhibitoire…

Cela dit ces critères ne peuvent pas concerner le nettoyage de la base actuelle. Là il faut déjà distinguer en gros à mon avis, une distinction qui vaudrait pour les modes d'archivage ultérieur:

  • d'une part les contributions «sociales» de la galaxie spip et divers articles non techniques du wiki, où j'ai plutôt l'impression que l'archivage relèverait ici complètement du cas par cas, d'une tâche éditoriale «à la main».

  • d'autre part les secteur-plugins et parties «techniques» du secteur-wiki, pour lesquelles je proposerais donc de se caler sur la date de sortie de la plus vieille version encore officiellement maintenue, désormais la 3.1. Donc d'archiver tous les articles tagués < 3.1, ou sans version indiquée mais antérieurs au 6 janvier 2016. Puis d'archiver les articles obsolètes postérieurs mais sans version indiquée, à voir s'il est possible de les traiter à la main, s'il n'y en a pas trop, ou si d'autres critères généraux sont applicables (dernière modif, dernier message…). Et taguer ce qui reste, articles postérieurs à janvier 2016 compatibles avec version max 3.1.

Sur la question des articles en attente ou en cours d'écriture, à mon avis ce qui n'a pas été publié peut être détruit, déterminer à partir de quand ça relève d'une politique éditoriale générale et des admin de rubrique, pas de l'archivage.

Sur la question de quoi faire des articles publiés obsolètes, pour moi, un archivage est un archivage, le volume sort de la collection directement consultable. Je comprends pas trop l'intérêt de laisser tel quel en ligne un article avec une mention «obsolète» ou «archive». Perso je serai plutôt pour des archives masquées mais avec possibilité de recherche (rechercher dans les archives).

Bref: un archivage initial assez radical, puis un bornage impératif pour un archivage automatisable par version pour tous les articles, un archivage plus fréquent également automatisable pour les articles de type actualité, des passes éditoriales régulières «à la main» sur les articles «sociaux» des secteurs galaxie et wiki. Et des archives accessibles seulement par critère de recherche.

Lupinacci Eric

Lupinacci Eric August 26th, 2019 08:04

Ben moi je rajouterais bien une mention dans le public et le privé sur le fait que l'article est archivé quand on tombe dessus tout de même. Après navigation et recherche ça parait suffisant oui pour exclure les articles archivés par défaut.

Maïeul

Maïeul August 26th, 2019 10:09

effectivement. J'avais oublié de le préciser, mais cela va de soi.

Maïeul

Maïeul August 26th, 2019 10:11

a mon sens les archives autres que doc sur spip (actualité, vie social) n'ont pas en tant que tel à être archivée, dans la mesure où l'information sur la validité de l'article est deja contenu dans le texte de l'article lui même. Si je tombe sur un article "rencontre spip le 3 mai 2011", bah je sais que c'est forcément de l'archive. Si par contre je tombe sur "comment faire xxx avec SPIP", je sais pas a priori si l'info est toujour valable.

F

fred August 26th, 2019 12:50

Oui, bon, alors ok on peut se contenter de bornes de version à l'avenir, je trouve pas ça très satisfaisant, mais à supposer que le ménage éclaircisse le paysage actuel, ce sera mieux que rien.

D'ailleurs le problème principal reste de comment traiter aujourd'hui l'existant sans bornes de version.

Combien d'articles ça représente? Peut-on discuter concrètement des différents critères proposés pour les traiter et trancher?

Est-ce qu'il y a consensus déjà sur le principe d'archiver les articles ne correspondant plus avec les versions maintenues?

Maïeul

Maïeul August 26th, 2019 12:56

En gros il faut relire. A mon avis ce n'est pas une grande partie, mais aucune idée. On peut trrès bien se créer un outil qui nous liste tous les articles sans borne.

je pense qu'il y a consensus de publier les articles ne correspondant pas aux versions maintenus.

la question pour les articles où la notion de "version" n'est pas perrtinente, c'est : comme determine-t-on que cela doit être archivée? personnellement je ne vois pas de criètres aisé.

F

fred August 26th, 2019 13:20

Mieux vaut dénombrer puis vérifier.

Si les articles sans version ne sont pas nombreux la vérification peut se faire à vue d’œil, sinon checker rapidement selon critère de date de publication / date de modification < date de sortie 3.1 ? puis vérifier ce qui reste, en espérant qu'il ne reste pas grand chose ?

Évidemment je peux filer tout coup de main possible pour la relecture et autre truc chiant.

F

fred August 26th, 2019 14:16

Ne pas ignorer non plus dans l'existant la possibilité que des articles tagués inférieurs à 3.1 soient pourtant compatibles 3.1…

Du coup une passe avec par exemple le critère de date de modification > 3.1 sur les articles tagués < 3.1 ne serait peut-être pas de trop, avec vérification. Sinon se taper tous les articles < 3.1…

Ou bien faut-il tailler à la hache tout ce qui est tagué < 3.1 ?…

RastaPopoulos

RastaPopoulos August 26th, 2019 15:02

De même je pense qu'il faut tout masquer dans la navigation, que ça n'apparaisse que dans la recherche ET qu'on a cliqué sur une case à cocher (ou un onglet de filtre) pour activer "Rechercher dans les archives". En revanche ces articles sont bien publiés, et indexés dans les moteurs de recherche Google etc, et liés sur des sites. Donc on ne doit pas perdre ces référencements, tout cela reste publié. Donc quand les gens finissent quand même par arriver dessus, il faut absolument un gros bandeau en haut disant "Cet article est une archive, donc obsolète, blablabla".

RastaPopoulos

RastaPopoulos August 26th, 2019 15:15

(Préambule, vous avez vu que dans un "gros sujet" Loomio (le descriptif tout en haut), on peut soit répondre au sujet racine, soit à un fil déjà commencé ? Là Maieul te répond explicitement à toi, et ensuite tu réponds bien Maieul suivant ce que t'écris, mais dans un nouveau fil, du coup on comprend plus trop, ya 12000 messages racines qui en fait sont la même conversation.)

J'ai l'impression que ça complique de penser que ça va être "plus automatique" en utilisant des bornes, alors qu'en fait ça complique et qu'il faudra en permanence tout relire de toute façon.

Car quand une nouvelle version sort, il faudrait de toute façon revenir sur tout pour augmenter la borne max, sinon au départ, quasiment tout le site passera en archive.

Pour moi il faut faire beaucoup plus simple, c'est en archive, si des modérateurs (ou propriétaires d'une contrib) ont décidé que c'était en archive. Point. Là on va faire une grosse relecture, mais ensuite ça sera une opération rare : quand il y a un signalement, sur IRC ou dans les forums, et bien les admins le verront, et se diront "ah oui tiens ça c'est trop vieux, on le passe en archive". Mais ça va absolument pas se passer souvent, il n'y a aucun besoin d'automatiser ça à outrance en imaginant des choses compliquées.

Si vraiment on veut utiliser les bornes, les plugins au niveau XML ont déjà des bornes, données par les devs. Si au moins une version du plugin est ok pour les versions maintenues de SPIP, alors TOUS ses articles = toute sa rubrique entière doit rester publiée. Il n'y a pas à avoir des bornes articles par articles, on connait la borne du plugin complet, et c'est alors bien d'avoir tout son historique (après c'est une autre histoire d'organiser ses articles pour faire apparaitre les choses utiles et récentes en premier, un bel article d'accueil etc). On peut toujours ensuite mettre à la main le fait que tel article est à virer en archive, mais pas besoin de bornes pour ça.

Pour moi un simple mot-clé ou plugin dédié (plugin archives, etc) suffit largement, un gros passage au début, puis des petits trucs ponctuels rares ensuite.

F

fred August 26th, 2019 16:03

(manifestement quand tu édites ta réponse à une réponse ou que tu quittes le formulaire ou quoi ou qu'est-ce, derrière ça t'ouvre un nouveau fil et pas une réponse… bref ça m'agace bien aussi mais sais pas d'où ça vient, je fais bien gaffe pourtant, je dois être neuneu )

Oui oui d'accord, c'est pourquoi je proposais de reformuler le problème et de commencer par se demander ce qui est archivable, pourquoi et comment avant de savoir si c'est et si ça doit être automatisable… bref, moi ce qui me gêne en l'état c'est le nombre d'articles manifestement obsolètes sans aucun moyen d'en être sûr a priori quand tu connais pas SPIP… donc il s'agit de régler le problème tout en évitant qu'il se reproduise.

Maintenant si on se cale sur les trucs déclarés dans les paquets, ben nickel, si besoin ça peut s'automatiser du coup mais oui une action humaine éditoriale est préférable. Cela dit le signalement extérieur, à moins que la communauté de devs et d'utilisateurs augmente grave d'un coup, et encore, j'y crois moyen pour toutes les contributions…

M'enfin ça ne règle pas le problème de l'existant et de son traitement…

Maïeul

Maïeul August 26th, 2019 16:07

oui, ca va de soi que, pour les plugins, le critères d'archivage par numero de version doit se baser sur les infos dans les paquet.xml, que c'est automatisable.

F

fred August 26th, 2019 19:29

OK, puisque c'est comme ça je m'en vais avec mes gros pâtés, na, vu qu'ils tombent n'importe où ici et que de toute façon ils vont de soi ^

Alors je boude mais reste dispo pour tous travaux pratiques, hein.

Tschüss

Lupinacci Eric

Lupinacci Eric August 27th, 2019 11:17

Oui, je suis assez d'accord avec cette approche manuelle surtout qu'il faut bien distinguer le premier nettoyage de rentrée et la gestion au quotidien (si tant est qu'il y en ait une après coup). Le plugin Contrib que je continue de développer a plusieurs buts : structurer le site, gérer des worflows utilisateur et fournir des contrôles automatisés pour vérifier les dérives ou les incohérences. Je préfère donc détecter des articles potentiellement archivables avec une heuristique à affiner plutôt que d'automatiser l'archivage.

Ensuite, si l'on considère les rubriques-plugin, une fois organisées, il sera facile de vérifier quoi archiver si besoin car je pense qu'on pourrait s'en passer. Au niveau de la recherche de toute façon il faudra appliquer la même logique que sur Plugins SPIP : par défaut on renvoie les plugins (donc les articles) compatibles avec la version courante de SPIP et si on veut plus, on le précise.
Il va rester des articles non plugins dispersés dans l'arborescence des plugins et qui soit décrivent des sujets généraux (sur les dates par exemple) soit décrivent des contributions utiles pour SPIP 1 ou 2. La question sera alors de savoir si elles sont encore applicables et sinon les archiver.

Enfin, le plus gros problème pour moi va consister à revoir le Carnet qui possède des articles de plugins jamais finis mais utiles, des sujets lancés et en plan, des sujets surement obsolètes... Là je nous souhaite du plaisir et de la force de décision si on veut avancer.

Maïeul

Maïeul April 16th, 2020 17:13

Un an après, reprenons ce sujet.

  • On a un plugin d'archivhage manuel, permettant de noter une date d'archive et une raison d'archivage.
  • en complément on a la possibilité de trouver facilement les compatibilités SPIP pour les rubriques associés à des plugins

  • On a semble-t--il un consensus pour ne pas afficher les articles archivés par défaut.

Reste à trouver consensus sur les raisons d'archivages.

Voici mes propositions
1. La fonctionnalité a été intégrée dans SPIP.
2. La fonctionnalité est désormais disponible sous forme de plugin.
3. La fonctionnalité correspond à une version trop ancienne de SPIP / d'un plugin.
4. La fonctionnalité est disponible ailleurs dans une version plus récente (cas des plugins).

J'insiste sur le fait qu'on dvera archiver manuellement des articles correspondant à des plugins absent du débardeur et donc de SVP (pour l'heure)

Lupinacci Eric

Lupinacci Eric April 17th, 2020 08:26

Hello,

Pour le point 1: faut-il archiver la contribution si ça décrit bien le fonctionnement ? Tu veux dire que le fonctionnement a aussi changé et que donc la description est obsolète ?

Pour le point 2, j'ai aussi la même question: ne faudrait-il pas mieux garder l'article dans la liste des articles du plugin en alertant sur son aspect fondateur si le contenu est encore valable du moins fonctionnellemment ?

Pour le point 3, ce n'est pas parce qu'une fonctionnalité est ancienne qu'elle n'est plus active dans SPIP actuellement. Je pense que c'est un problème de formulation. La fonctionnalité est obsolète car elle a disparu de SPIP (du moins dans l'expression qui en est faite) ou elle a disparu du plugin ou le plugin a disparu. Pour moi c'est ça le cas essentiel pour les rubriques-plugin : le plugin n'est plus maintenu (ce que l'on sait rarement), il a été remplacé par un autre, il n'est plus zippé, on le trouve plus sur la zone.... Pour moi c'est ça les raisons majeures qu'il faudrait lister.

Point 4, je ne comprends la formulation.

Ne pas oublier aussi que le gros du ménage qu'il reste à faire ne concerne pas les rubriques-plugin mais les autres secteurs comme la vie de SPIP, le carnet et le débarras qui est dans un secteur nommé _A trier & Archives avec beaucoup de choses plutôt moisies. En fait, il faudrait repasser dessus pour avoir une vision plus claire des cas d'archivage.

RastaPopoulos

RastaPopoulos April 17th, 2020 08:58

pitêtre faudrait-il un ou deux exemples pour chaque propositions de raisons, à la fois afin de comprendre à quoi ça se rapporterait et pour "prouver" que c'est un cas réel d'utilisation

Maïeul

Maïeul April 17th, 2020 09:27

1.La fonctionnalité a été intégré dans SPIP. Exemple auquel je pense : SPIP-Bonux (ancienne version). A mon sens si le fonctionnement est bien décrit, dans ce cas l'article devrait être migré dans spip.net
2. Exemple auquel je pensais : toutes les contributions sur comment faire un agenda, ainsi que les articles sur les fonctions à placer dans mes_fonctions.php. A mon sens cela devrait être masqué par défaut pour que l'internaute voit ce qui est fonctionnel immédiatement, quitte à renvoyer vers l'article fondateur (archivé) dans les autres autreicles, à titre historique.
3. Effectivement, obsolète serait le mieux. Je pensais précisement à HTLML5up Hyperspace v2 qui sera remplacé par v3, et pour laquelle on semble être arrivé à un consensus qu'on ne devrait plus référerer. On pourrait effectivement affiner la typologique
4. Correspondait en fait à une sous partie de 3.

Je me demande si on devrait pas finalement avoir une approche "pragmatique" en typologisant aux fur et é mesure les vieilles archives, puis en faisant une repasse general dessus pour vérifer la cohérence, plutot qu'en cherchant une liste à établir "a priori".

Lupinacci Eric

Lupinacci Eric April 17th, 2020 09:43

Oui je pense comme Rasta qu'il faudrait faire une première passe pour définir une typologie de base qui pourrait évoluer ensuite. C'est un peu ce que tu proposes mais je pense qu'il faut se faire une première liste car par expérience c'est grand Contrib !

En conclusion, je vous propose qu'on accumule une liste d'articles potentiellement archivables en mettant un proposition en face. Faisons ça chacun de notre coté en trouvant des exemples significatifs et on se fait un point ensemble quand on a une liste pertinente et suffisante non ?

Maïeul

Maïeul April 17th, 2020 09:48

faisons à ce moment là un tableau collectif à 3 colonne
1. Id article
2. Titre
3. Typologie proposée

Lupinacci Eric

Lupinacci Eric April 17th, 2020 10:18

Ok, go go go

Maïeul

Maïeul April 18th, 2020 21:09

voilà https://drive.switch.ch/index.php/s/FsGaGtzHX8izsSv
c'est éditable en ligne via onlyoffice.
Je propose qu'on commence par parcour tout les objets avec des mots historiques d'archivages (au moins 3, + de 1000 objets)

RastaPopoulos

RastaPopoulos April 19th, 2020 14:33

En fait j'ai une question préalable, avant de faire une chose, c'est pourquoi le faire ? :)

Plus précisément : pourquoi est-ce que les raisons d'archivages sont une liste normée statiques définie en amont ? Vouloir tout transformer en liste normée est un peu une mentalité d'informaticien, si ça n'a pas un but final. Donc quel est le but final, est-ce qu'il y a réellement une utilisation connue à trier les archives par type normé ? Moi il ne me semble pas du tout, au contraire il me semble que l'utilisation principale et la plus courante des "raisons d'archivage" c'est juste… afficher une phrase expliquant la raison. Point.

Et pour ça un simple champ texte suffit (même juste input pour forcer à donner une raison synthétique).

Cela permet beaucoup plus de liberté, notamment pour ajouter du contenu personnalisé comme un lien, à chaque fois. Ce qui est pour le coup bien plus utile au lecteur qu'une phrase bateau toujours la même.

Exemple : "Cette fonctionnalité est désormais fourni par SPIP : documentation de la balise #TRUCMUCHE (lien vers spip.net ou programmer ou autre)"

Maïeul

Maïeul April 19th, 2020 14:39

L'intérêt que je vois à la liste normée est surtout une uniformisation
des présentation, et aussi de nous donner à nous des règles un peu
claires de pourquoi on archive.

Cela étant, mon travail sur les 50 premiers cas me montre que dans
certains cas l'archivage répond à plus d'une raison, et donc il faudrait
pouvoir en attribuer plusieurs (sauf si on laisse un champ libre).

RastaPopoulos

RastaPopoulos April 19th, 2020 14:55

La présentation c'est juste du HTML-CSS, quelque soit la phrase à l'intérieur du bloc, on peut la présenter pareille, du moment que c'est toujours une taille similaire (pas une différence entre 1-2 phrases et 5 paragraphes quoi).

Donc je ne vois toujours pas d'argument sur pourquoi les phrases elles-mêmes devraient être toujours les mêmes, au contraire ça ne donne aucune info super pratique aux lecteurs. Cf la différence entre "Cette fonctionnalité est fournie par SPIP" la même phrase partout 200 fois, et "La balise #TRUCMUCHE est maintenant fournie par SPIP (lien vers sa doc)". Là ça aide directement les lecteurs à aller au bon endroit sans fouiller X sites. Normer/catégoriser/typologiser ça sert seulement si on doit faire des tris, des filtrages. Ce qui n'est pas le cas (je ne vois pas où ce serait utile).

De même, si on a de multiples raisons, encore pire. On rentre dans des "oui mais" en cascade (oui mais ya une autre raison aussi, oui mais on a pas pensé à celle là en amont et va falloir la rajouter après coup), avec un choix technique compliqué (concevoir et déclarer une liste en amont en PHP, etc), alors qu'en fait un simple champ input "Raison" suffirait pour notre utilisation (et pour 99% des cas d'utilisation de ce plugin à mon avis).

Maïeul

Maïeul April 19th, 2020 14:58

oui, réflexion faite tu as raison, je ne vois pas quel usage on aurait
d'une typologisation

Lupinacci Eric

Lupinacci Eric April 20th, 2020 06:58

Ben moi si.
Par contre, je pense qu'effectivement à l'usage un texte d'explication peut être aussi important car même si on dit que c'est une obsolescence de plugin on peut vouloir donner le plugin remplaçant. Donc je suis pour rajouter un champ explication mais je souhaite garder la raison comme une typologie car c'est bien de pouvoir chercher les plugins obsolètes ou une autre raison de ce type. Et puis vous oubliez aussi que tout le monde n'a pas envie de passer du temps à faire quelque chose pour les autres et on risque de se retrouver avec n'importe quoi comme explication à la longue.

Donc ma proposition de compromis :
- on continue à définir une liste de raisons
- je rajoute le champ texte qui va bien pour compléter

Pour une fois qu'on peut tous être contents on va pas s'en priver, non ?

RastaPopoulos

RastaPopoulos April 20th, 2020 09:44

Je vois toujours pas à quel moment dans l'interface ça va être utile, et pour qui. Complexifier la mise en place et l'interface d'édition pour quasi personne qui va utiliser le résultat final… Surtout que ça sort pas "les plugins" mais n'importe quels articles. Spécifiquement pour voir les plugins obsolètes faudrait plutôt ajouter un statut obsolète/deprecated vraiment aux plugins eux-mêmes (ya ça dans certains autres gestionnaires), là ouais, info alors utile n'importe où pas juste dans Contrib.

Le plugin est générique, c'est une refonte encore plus générique de l'ancien plugin d'archive, c'est pas spécialement propre à Contrib. Or vraiment, je pense que 99,9% des utilisations de ce plugin n'auront jamais besoin de catégoriser de manière normée les types d'archive (qu'on me donne des cas d'utilisations réels et courants).

Si ça doit y être dans le plugin
1) lors de l'installation ça ne doit pas remplir de raisons par défaut et
2) si la liste des raisons est vide alors dans l'édition ça ne s'affiche pas.
=> On n'aurait donc que le champ libre par défaut, sans aucune complication de mise en place. Et pour Contrib, tu remplis une liste de raisons et là ça apparait. Comme ça le plugin reste simple par défaut et c'est seulement si on veut qu'on le complexifie.

Lupinacci Eric

Lupinacci Eric April 20th, 2020 09:55

Oui on peut activer ou pas la raison. C'est d'ailleurs le cas avec la config il me semble.

Pour les plugins obsolètes c'étaient d'ailleurs une de mes interrogations sur l'archivage dans Contrib puisque on y intégrera Plugins SPIP ne faudrait-il pas avoir un statut d'obsolescence de plugin et si oui, quid avec l'archivage. Mais bon, chaque chose en son temps.

Maïeul

Maïeul April 28th, 2020 18:25

Le lien était pas bon, il était pas modifiable.
https://drive.switch.ch/index.php/s/7SaOGcN86voc2Dj
est mieux
francky va essayer d'avancer sur cette typologie.