Yop, bonne année à tous,
et merci à toi pour tout ce boulot déjà !
Pour le point 1, nettoyer, qu'est ce que ça signifie concrètement ?
Il y a des discussions sur les contenus à supprimer / archiver / déplacer ? C'est organisé quelque part ?
Hello,
Les prochaines étapes sont :
1- continuer à nettoyer les rubriques de Contrib qui ne sont pas des
plugins (carnet, contribs diverses, la vie de SPIP…)
2- mettre en place la logique d’archivage ds articles de Contrib et des
plugins SPIP (plugin archivage des contenus et état/balise dans le
paquet.xml). Il me reste aussi quelques questions à régler suite à la
réorganisation que j’ai noté dans une liste que je publierais bientôt.
3- développer le dashboard des administrateurs du site pour maintenir sa
cohérence.
4- développer des workflows utilisateur pour faciliter le travail
rédactionnel sans se préoccuper du rangement dans Contrib.
5- intégrer les pages de Plugins SPIP dans Contrib et faire évoluer la
recherche en conséquence.
Pour le point 1, nettoyer, qu’est ce que ça signifie concrètement ?
Il y a des discussions sur les contenus à supprimer / archiver /
déplacer ? C’est organisé quelque part ?
1- Nettoyage
Pour le carnet :
- relire les articles qui portent sur des plugins réalisés et déjà en production depuis parfois longtemps et les transférer dans la rubrique-plugin associée (à créer le cas échéant). En fait, j’ai déjà eu l’occasion de le faire au cours de la réorganisation et je pense qu’il est possible qu’ils restent encore des articles de ce type.
- repenser l’utilisation de ce carnet : n’y a-t-il des articles plus globaux qui aussi gagneraient à réintégrer l’arborescence des catégories ?
- repenser en cohérence avec le point du dessus l’arborescence si besoin.
- ne faut-il pas archiver certains articles et pour quelle raison (voir le chapitre sur l’archivage) ?
Pour le secteur sur la vie de SPIP :
Je suis passé assez vite sur ce chapitre mais il y a un peu à boire et à manger dedans. Les actions purement éditoriales seraient :
- définir la typologie de contenu et en faire un sous-rubricage
- ranger les articles suivants ce nouveau rubricage
- identifier les articles à archiver et la raison de leur archivage (voir le chapitre sur l’archivage) ?
A trier & archives
Le titre dit presque tout.
- Il faut trier ce qu’il y a dans ce secteur et le répartir dans le reste de l’arborescence : ce secteur doit disparaître à terme.
- Il faut de même identifier les archives mais en détricotant les rubriques poubelle d’archives (voir le chapitre sur l’archivage).
Pour tous les secteurs
Il existe des articles :
- refusés : que fait-on de ces articles qui parfois datent de plusieurs années ? Ne devraient-on pas les supprimer à partir d’une certaines date ?
- en cours de rédaction depuis des lustres. Que faire ? je me dis qu’on pourrait envoyer un mail à l’auteur pour lui demander si il compte faire quelque chose et sinon le virer. Certains datent de plus de 10 ans…
- proposés à la publication depuis des lustres. A décider par les admins non et si non on repart dans les cas précédents.
Les auteurs
C’est pas une obligation mais est-il nécessaire de conserver 8042 auteurs alors que très peu en comparaison sont des rédacteurs ?
N’y a t-il pas une action à faire en concertation avec l’auteur si possible ?
2- Archivage
Ce qui a été fait :
- pendant la réorganisation j’en ai profité pour supprimer toutes les rubriques « archives » créées en « prévision de » et toujours vides. J’ai laissé celles qui avaient du contenu en attendant de décider comment les traiter.
- le plugin « Archivage de contenus » a été développé et permet d’archiver des articles et des auteurs (et plus via un pipeline) en autorisant la saisie d’une raison d’archivage (et de désarchivage le cas échéant). Les raisons sont saisies dans une liste composable via un pipeline. Il est donc possible d’archiver tout contenu souhaité sur Contrib et de faire en sorte qu’il soit exclu par défaut des boucles sauf à préciser le contraire.
Une liste des archives par type de contenu est disponible.
Quelle stratégie ?
J’ai acquis plusieurs convictions pendant mes travaux de nettoyage, mes lectures d’articles et le développement du plugin d’archivage:
- éviter les rubriques « archive » qui crée une structure peu compréhensible dans le site (car non systématique) et qui induit une perte de l’historique.
- distinguer la méthode d’archivage des articles liés à un plugin et des articles non liés à un plugin. En effet, « l’obsolescence » d’un plugin ne peut pas être traitée par l’archivage d’un article voire d’une rubrique.
De fait, je propose de voir l’archivage sous les angles suivants :
-
Pour les articles non liés à des plugins (donc en particulier ceux des secteurs concernés par le nettoyage précédemment discuté) il faut utiliser le plugin « Archivage de contenu » en définissant une liste standard de raisons. C’est la partie simple de la proposition. Il faut juste identifier si il est nécessaire d’y inclure les objets sites voire brèves (je crois qu’elles ont été désactivées non ?)
-
Pour les articles liés à un plugin, là c’est plus complexe à mon avis.
Mais je serais d’avis de travailler sur le plugin lui-même.
Aujourd’hui dans SPIP on a 620 plugins 3.2 environ, 720 compatibles 3.1 et plus de 900 compatibles 3.0.
Pourquoi certains ne sont pas passés en 3.1 ou 3.2, on ne le sait pas surtout pour ceux qui sont clairement devenus « obsolètes »
A contrario dans Contrib on trouve :
- des plugins 3.2 dont certains articles sont archivés
- des plugins du grenier qui sont affichés bravement et dont aucun article n’est archivé
- des plugins non zippés qui sont toujours accessibles par une rubrique mais cette rubrique n’affiche pas le préfixe et on ne sait donc pas si ce plugin est encore valide, intéressant, maintenu…
- des plugins documentés mais dont les zips ne sont plus accessibles (ça milite pour éviter les zones perso qui ne perdurent jamais d’ailleurs).
Donc c’est un peu le bordel et ça fait pas trop référentiel.
D’où je pense qu’il faudrait :
- arrêter de se baser sur les archivelist pour définir le référentiel
- intégrer tous les plugins existants dans le référentiel (ce qui devrait être simplifié par le passage sous Git) et essayer de faire venir les externes sur la forge ou les rendre accessibles
- utiliser la logique de maintenance SPIP pour automatiquement qualifier un paquet/plugin (si le plugin ne propose pas de paquet compatible avec une version de SPIP maintenue il est considéré comme déprécié SPIP)
- définir soit une balise dans le XML soit une typologie de tags (mieux avec SVP typologie) permettant de tagguer les paquets/plugins « obsolètes » avec la raison de l’obsolescence (liste à définir).
- exclure des boucles les plugins obsolètes pour toutes ces raisons.
De fait, je n’archiverais jamais les articles liés à un plugin. D’ailleurs c’est difficile à faire car souvent les articles nouveaux sur une version ne reprennent pas des informations encore valables données dans les articles antérieurs.
Tout n’est pas encore sec mais en tout cas c’est l’orientation que je donnerais à cette problématique.
Vos avis sont les bienvenus.