Re: Bonne année à Contrib !

Eric Lupinacci <[email protected]>
Newsgroups gmane.comp.web.spip.devel
Message-ID <CAM6W4bZLqJhDFcY7v5H34y0_fU1tzTtO9_fJJ9L93FuNeqrrWA__8187.97398112423$1578308424$gmane$org@mail.gmail.com>
Hello,



Le mer. 1 janv. 2020 à 17:09, nicod_ <[email protected]> a écrit :

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

++
Eric
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.